 Hello my name is Steve Grubb. I work on Common Criteria, you know the Broadhead Security Engineering Group. I've done six Common Criteria evaluations over the years and I have Mark Thacker here is going to help present some of this. Yeah, hey everyone, I'm Mark Thacker. I'm the Product Manager responsible for security in Red Hat Enterprise Linux and I'm going to be talking as we go through Steve's gonna go in a deep dive about what Common Criteria is and the very specific definitions and I'll take you through just a very quick summary of where we are today in Red Hat with well Common Criteria where we're headed in the future as well. Thinking about some of this maybe the first time I've publicly said it so it's like a shy nose that's all. Okay so this talk is intended to be sort of a Common Criteria 101. You know if you don't really know much about Common Criteria that's kind of the level of what this talk is aimed at. And what we're going to go through is basically the different parts of the security target. Protection profile will go over some of the terminology and then we'll you know pull it all together about you know what an evaluation is and what does and then I'll hand it back over to Mark. So to get some sort of frame of reference let's listen into a conversation a fictitious conversation with a salesperson and a customer. You tried out our new X, Y, Z, O, S. No, why should I? It's so secure. How secure? Very. Prove it. Okay what would it take to prove it? I'd like to see independent third party review that includes a code review, testing, review of the development process, a list of security features and the threats they counter, security guidance so I can lock it down, and a vulnerability assessment so that I know that you've patched everything. Is that all? Maybe some penetration testing because bad guys do that too. Sounds like a lot of work. Maybe so but serious claims demand serious proof. So what is our sales guy going to do? What's the company going to do? Well unbeknownst to him the customer just specified Common Criteria. Common Criteria is an internationally agreed upon set of requirements that facilitates comparability between security valuations. It sets a common set of requirements for functionality with a certain product type and it requires a certain assurance measures to be applied during the development and evaluation. This is sort of a visual concept of what is happening here and instead of owners, which owners would be the purchaser, I would rather substitute the word developer into this and so developers impose countermeasures to reduce risk to assets. The customer owns assets they don't want the bad things to happen to. Owners wish to minimize risk and owners value their assets. Meanwhile we have threat agents that give rise to threats that increase risk to assets and the threat agents wish to abuse and or make damage those assets. So let's take a look at some common terms, acronyms and terms used in Common Criteria because these slides are going to have all of this on it and just want to make sure that you guys are familiar with some of these terms before you see the slides. First one is TOE which is the target of evaluation and what that means is it's the hardware with the software installed. Protection profile. This is a set of requirements for a product type and we'll discuss this in more detail. ST is a security target and what that is is a customization of the protection profile for a specific product. TSF is the target of evaluations security functionality. SFR is a word we're going to run across a lot. It means the security function requirements. A couple more terms. Developer. The company that makes the product. Scheme. That's the government agency that sets the security rules. There's there's several schemes you know like NIAP is in the United States, BSI is in Germany, Spain and Turkey, Italy you know France, Canada. They all have schemes also that set the security rules. Assurance. This is the confidence that software is free from vulnerabilities either intentionally designed into the software or accidentally inserted. Okay so when you get into the security target one of the or production profile one of the introductory sections is about threats and this is an important section to be able to take a look at because this tells you what the people that wrote the production profile had in mind when they when they wrote it. So the definition is that a threat consists of adverse actions performed by a threat agent on asset. There's an example that I have here that says T local attack T meaning threat. What this particular one says is that an attacker made compromise applications running on the OS. The compromised application may provide malicious formatted input to the OS through a variety of channels including unprolique system calls and messaging via the file system. So this would be you know something that that they wanted to counter. This is a threat they saw you know to the to the operating system and so you know this is one of the things that they list. Another section is going to be assumptions and this is the accepted beliefs around the operating environment that the security function will not address like for example down at the bottom we have a proper admin and what this basically says is that the admin of the OS is not careless willfully negligent or hostile and the administrators of the OS will within compliance of the applied enterprise security policy. So what that would mean is that all the security measures are not intended to protect against the malicious admin another section in the in the beginning is the security objectives. This is a concise and abstract statement of the intended solution to the threat. I have an example here from OSPP called the protected comms. This one says that to address both passive eavesdropping and active packet modification network attack threats conforming OSes provide mechanisms to create trusted channels in other words it's an encrypted that they want you to use cryptography to protect the communication. Okay so once you get past this introductory section you you finally get to something called SFRs which is the more concrete things that you're expected to do as a developer. The SFRs are a translation of the security objective into a detailed and complete level of extraction but independent from any specific solution and the reason that that they do it this way is so that they can say that they want us a certain kind of protection but Microsoft has the leeway to solve it their way Linux vendors can solve it their way Macintosh can solve it their way so they don't specify a complete solution but they give they give something that we can all do and and an example from common criteria part two they have a requirement here that says when the defining number of unsuccessful authentication attempts has been and then you have a selection it says met or surpassed then the TSF shall do something. So this is not very detailed okay so the SFRs is really the meat of common criteria and this shows all the different families of security functionality that that the catalog has so common criteria part two is a huge catalog of all these different security functionalities and within these families there's a lot more yes there's a lot more Let me see. I have a pointer here. Yeah. So the major ones that you would run across in a protection profile is under protection of TSF and user data protection you know like for example access control policy this one is one that would define your permissions on files and being able to access things but in any event I just wanted to show you that that there's a lot of different kinds of requirements you know in in the catalog but you don't have to know about all these things because normally you run across a protection profile which has already pre-selected the ones that you that you need to care about. Speaking of protection profile a protection profile is intended to describe a type of a product. It contains the threats, objectives, assumptions, everything that this kind of product may encounter. The people that write protection profiles is generally a government that is specifying its requirements as part of the acquisition process. There's a lot of different protection profiles out there there's probably 30 or 40 of them just just under NIAP and what it is I just went and picked a few of them to just give you a feel for the different kinds of protection profiles that are out there application software that's to address things like a Java server or a Java servlet. Then there's operating system protection profile which is the one that that I care about there's full disk encryption network device there's a protection profile if you want to be a firewall if you want to be a VPN gateway there's one for that if you want to be a multifunction printer there's one for those mobile devices these things go through common criteria also USB flash drive the one you had that thing goes through common criteria smart cards VoIP all these things can go through common criteria the security target is is a further detailing of the of the PP and explains how you know this combination of software and hardware meets the security objectives and this it talks about exact technologies like SELINX PAM kernel you know at this point this is this is really where you go from the abstract to you know this is how we're going to solve the problem the other thing too about the security target is it serves as a basis of agreement between the developer and the evaluator on the exact security properties and the exact scope of an evaluation so in other words when when a company writes a security target they give this to the lab and this is what the lab tests exactly okay and one last thing to talk about here is that yes as we saw in that example of the the SFR there are electives you know where somebody has to make decisions about how how this requirement is met and I have an example down here that shows the before and after like this this section here in the middle comes straight out of the common criteria catalog which you know it's the same requirement we saw earlier and when a defined number of unsuccessful authentication attempts has been then selection met or surpassed then the TSF shall do something so it was it was refined in the actual security target to say when the defined number of unsuccessful authentication attempts has been met the TSF shall disable user log logon account until it is re-enabled by the authorized administrator so you see how it gives you some room and then you know you tell how it's solved normally there's one step in between and that is that the the scheme takes out of the catalog and then they do some selections in other words this is this assignment where it says list of actions they go ahead and populate that list with the things they would like to see you do in other words they kind of give you a hint and how they want to see it solved and then you have to pick from that list okay one one other set of requirements these are the ones that normally don't like and this is the assurance requirements which describe what the evaluator will do to confirm that the SFR is met it also specifies things like you have to use get or some kind of version control system and it specifies you know other things like training you know of staff and locks on doors to make sure that people just can't come in and commit code so there's a lot of things to assure the assurance activities but there's some that are specific to the SFRs and I have some examples here just to show you you know the nature of what's expected and it says you know the evaluator will attempt to modify all shared libraries that are used throughout the system and you know if if the system's designed right you know the files are owned by root and you can't modify anything as a common user okay so to tie all this together the developer or company picks a protection profile that protection profile is supported by a specific scheme which you know means a nation the scheme has accredited a number of labs that it tests periodically to verify their capabilities the developer contracts a lab to conduct the evaluation of the security target following the assurance activities to prove that the tow counters the threats the lab then conducts these tests and submits paperwork to the scheme the scheme reviews the documents and if everything is good they issued the certificate otherwise they they tell the lab that there's some problems and it goes back to the developer where they may have to do more testing and documentation and you know ultimately you know a certificate is issued and then all signatory come countries to the mutual recognition treaty accept this evaluation okay so how can developers help for the product type that you have you know you'd want to find the protection profile if one exists because you know not everything exists like for example in containers there is no protection profile for containers at this point but if you work on firewalls you know there is definitely a protection profile for that so what you want to do is look at the SFRs and see if if you if their product already meets them all or you can configure it to meet them all if the SFR has electives then you want to try to provide as broad a coverage as possible so that scared target writer can claim as much as possible so in other words in the cryptography section they may list you know 10 different ciphers you know that are acceptable and so what you would probably want to do is to try and support all 10 of them if you can so you can claim all 10 of them I mean you might be able to get by on one or two but the market probably is you know your competitors are probably on support all 10 so that's that's how you can help is to read the PP look at the SFR see if you meet them if not fix you know do something to meet it and try to provide as much coverage as possible okay so I want to take you through just real quick and the remaining time that we have available about where we are with common criteria today Steve already kind of set this up but if you're a developer in the room most obvious question and that's great why should I care there's lots of reasons to care number one because our customers everybody has customers require a common criteria it's a purchasing requirement and given two products of equal capability the one with common criteria certification is the one that they will buy one that they must buy especially in the US in many situations it's just plain mandatory they just have to buy the other reason why should you care other people are doing it right other vendors are doing it but most importantly as a developer because of all of those reasons you worked really hard on your code and you want your technology to be in the hands of people that actually want to use it thus you care about common criteria so where are we today redhead's been doing common criteria for a very long time and generally for the operating system we have picked the general purpose operating system protection profile GP OSPP and we have actually evaluated well seven twice against OSPP version 2.0 and OSPP 3.9 on Intel XA664 and IBM Power Architectures now anyone want to tell me how old 7.1 is it's actually end of life right you cannot get support from redhead anymore in 7.1 in practice in the field typically what we find is customers will use our protection or rather our security target and the report that came out of evaluation as a continuation and a justification for you for using newer versions of the operating system however we're moving forward so there's been a lot of changes in the US in particular we're on common criteria and we have a new general purpose operating system protection profile version 4.2 the nice part about this evaluation process under 4.2 and deny app is it's extremely fast what I mean by extremely fast okay we're talking common criteria definition of extremely fast now it we are required once we actually formally enter into certification to complete the certification within 180 days typically 90 to 180 days this 7.1 evaluation I was born I guess when we started it it took two years two years to actually go through evaluation right two years 180 days wow it's like lightspeed buddy so it's a lot faster now in reality what that really means is there were significant changes to how the evaluation process is being conducted is much more automated and test-driven now so the bullet line that was the lab conducts the test gathers the reports and then submits it that whole process is now significantly more audited and more automatable than it used to be as a result of that however this is a new schema and there are some limitations for example under 7.6 no one in the world rather under OSPT 4.2 there is no such concept as mandatory access control you cannot test se linux under OSPT 4.2 doesn't exist there's no concept of mandatory access control that's going to be a problem long term because we have customers that use I don't know containers with se linux is fewer in the last and also if you're into labeling like MLS environments you need se linux mandatory access control so Steve and other people are working on creating enhancements to OSPT that hopefully will be accepted by NIEP and others so that we can in the future evaluate against mandatory access control good news now is actually no one in the US under OSPT can also mandatory access control so 7.6 we are in the process of becoming fully in evaluation and talking about that more publicly but this is the target that is something that we're actively working on right now what about moving forward rel 8.0 is designed from the beginning to be common criteria certifiable I did not say that we were certifying 8.0 because this is a major new release we want to make sure if there's any issues we shake it out right in the operating system and in the protection profile itself so for example one of the things that changed in Red Hat Enterprise Linux 8 is TLS 1.3 there were at least two talks on TLS 1.3 in this room today TLS 1.3 is not covered under the OSPT 4.2 that we're using for rel 7.6 so there will likely be an OSPT 4.3 that will include TLS 1.3 support so the plan is that we will target the next minor release of rel 8 I guess I'm not technically supposed to tell you what number that would be but point some number greater than zero on the end that would be our target for common criteria for rel 8 and as I was mentioning earlier we're going to be adding mandatory access control and for example under new OSPT 4.2 secure radius and absolute requirement UEFI secure boot is a requirement IBM power systems currently don't do secure boot they have other ways of making sure their environment is secure but they don't do secure boot they literally cannot be evaluated under this model as of today there are enhancements going on in the hardware side there's maybe some things that we might be able to do in the protection profile as well so I have my own what's what's next for you so learn about common criteria you're here today learning about it if any of you are working on any of our layered products open shift directory products identity management products virtualization infrastructure look again as Steve indicated is our protection profile that's interesting for you if so then let's talk right we have most of the common criteria experts here in this room if you're a developer involved anywhere in what we call our target of evaluation the toe which is basically down in the kernel just be aware what you're working on is what's being evaluated right so just be fully aware of that and with that I think we actually stopped exactly one ah look at that the players that 525 we are at the end so thank you for waiting on questions you guys have any questions for us yes good question yeah so it doesn't really matter what it touches or does not touch let's look at the line I didn't read evaluation only plus the operating system itself so by definition no now it doesn't inherit so for example you could not claim what common Ansible is common criteria sorry for because it's running on a common criteria certified version of route no that doesn't work that that inheritance doesn't work now what does work is something like FIPS where you're not inheriting FIPS certification for Ansible but you can claim hey look the new version of Ansible has been made to run in a mode where if rel is in FIPS mode the Nancy will use nothing but FIPS validated cryptographic routines it's not that Ansible itself is FIPS validated or FIPS certified none of those words apply it's just compatible with rel running in FIPS right so common criteria no because the certification does not automatically inherit to any layered product that's where you get into interesting conversations like our rev product red hat virtualization it's based on rel oh but it doesn't apply immediately right because it doesn't inherit upstream also there's actually a virtualization protection profile so now you're into a different user space a different use space you need a different protection profile it does cause confusion well actually though there's there's nowhere to hand claim on containers in OSP before that too under OSPV 2.0 which is the old EAL style of evaluations there there were protection of the TSF requirements there and so you could hang claims there saying that you know provides process isolation but you know you come out from that angle you know but you know I've also been talking with Niant about how we could do a certification of containers and what their initial thoughts are is that you know it's another kind of virtualization so what we want to do is take a look at virtualization protection profile and start with that throw away things that don't make sense for containers and throw you know add some things back to it that are specific to containers but you know generally follow the virtualization protection profile and write a security target and then if we are successful in evaluating a security target come deny up and say hey this this could be a protection profile that everybody has to meet and they would consider that as a as a new baseline you know they're right now they're looking you know I'm looking to industry to figure out you know how what what to claim about security around containers and I know Sean and I were talking just this week another thing you can do is there's a fairly broad protection profile called application it's actually an application server yeah and that's kind of a catch all category that we could classify a lot of things and including open shift as a whole application might be able to get away with that it's a little different because it doesn't treat doesn't treat like open shipped as a virtualization platform there's a lot of leeway but the short answer to your question Dan is yeah it causes confusion okay two more questions the subject right right so the question for the camera was basically long-term maintenance of common criteria released operating systems right once you have maybe new CDs and patches I mean you didn't say that but I assume that's what we talked about how do you keep it up to date and how does that deal with certification how certification deal with those changes right yeah so what certified is exactly what we passed through the lab we can do maintenance updates on that certification so at certain points of time we can take an rolled-up patch set and ask the lab and say look here's everything that's changed since last time that we certified this is what it did or didn't do to the security target our claims around what we certified and typically that's a very fast kind of recertification if you will of an update of a patch release of a patch in reality an auditor at say a government agency understands okay you certified this it's been 90 days there's new patches we get it you have to install those patches and auditors generally will work with you and the security target and understand what's been changed but I don't know if you have any other I was going to point out that the protection profile actually does call up for time security updates so they know that there's going to be changes it's actually in the requirements press to do that kind of thing it just that they also would like us to reevaluate within two years you know to just keep it fresh but anyway so they expect the expect updates and we going forward our plan is with 7-1 for example you had two evaluations now we're doing an AM 76 going forward without being too specific we intend to have no problem with that less than every two years I could get it out to once a year that would be really great you talked about that we definitely do common criteria for the OS protection profile and we also do one for a certificate system what other systems are common criteria within Red Hat that have been evaluated or in process of value we need it right now Jboss EAP goes through certification all the time every couple of years all the major releases of Jboss EAP go through certification other than that we have done virtualization extended module we've done the advanced audit extended module in OSPP2 and that one was designed so you don't actually do another security target or protection profile but it was modular but looking at competition like for example Microsoft took Windows 10 through the firewall, the VPN, full disk encryption and operating system so vendors do normally take their products through several things to cover different aspects of the product when other Red Hat layered products are evaluating it they're honestly waiting for business cases Rev has looked at it, OpenStack has looked at it, we're in active discussions around what to do with OpenShift since it's so rel-based and especially moving forward it's still very much rel-based but yeah you've got the three that we can point to right now Yes Okay so for those kind of requirements, you know, I personally am going to give you a call Now you know who to bribe, I'm just saying that the major piece is not a PAM, I don't know if you're not going to have to verify or anything and make sure everything is using PAM, it uses it correctly but you're right, we can't look at all of it Red Hat depends on the package maintainers being familiar with upstream, being embedded with upstream watching bugs upstream, back playing bugs as we see things happen but then once they, you know, we get the package, you know, it runs into door for a while and we get a little bit of confidence that, you know, the package is in good shape, you know, from running in Fedora so then, you know, it comes into rel and when it comes to the rel, we run it through a covariate source code scan and so, you know, it goes through it and gives us reports, you know, about all kinds of different defects that, you know, define, but at the same time we also turn on other different modules so we get the report on C, Java, JavaScript, Python there's a shell code checker and then we also get reports from CPP check and then also the compiler team is working to add diagnostics to the compiler so, you know, the package maintainer is kind of more than enough information, you know, about what's going on with that code and so they can help find some of the worst spots you know, then, of course, those patches go back upstream and we can find things, we can give them back upstream and make sure that upstream agrees that, you know, the patch really fixes the code and so, you know, we just completed this cycle back in the summer for rel 8 there was a bunch of activity around August, you know, for this kind of thing but, you know, it's generally enough that, you know, we can show the plan you know, that we have our package maintainers embedded in that stream they are sometimes the leader of the activity so, you know, they have their hands on the code but we can also show that we've run these scans and that, you know, we've fixed a number of these things and we've went to Buzzilla to show them we fixed some of these things and so that's how we can, you know, try to create an assurance case we can't fix everything, you know, if you get away but, you know, we do make a big effort and this is a lot of work and we are out of time thank you guys, I appreciate very much