Okay, so I'm going to dive right in. Thank you for coming to my talk. I know you have a wonderful selection of accessibility talks in this time slot, so clearly this is the one that's still in the scalable. I have, if you follow me on Twitter at all, I'm sorry, but I noted that I had 108 slides in 40 minutes, and after a lot of work I've gotten it down to 120 slides. So we're going to see how many of those I get through. To manage your expectations, all of my slides will be available online later. And I'm saying this now partly because as I manage my own, as I manage my own time, I have a whole chunk of slides that I'm just going to fly through because they're mostly technical stuff. And the nice thing about technical stuff is it's so boring that you guys can't read it at your own time, and what we call sleep, I won't be personally heard or watched in film at times. I really thought you'd come to film me off this day. Such an auspicious start. Quick question, how many people here use WordPress for CMS or a blog platform? That's good, okay, most of you. How many of you use, in addition to WordPress, some other platform besides WordPress than they blog or CMS platform? Okay, usually I see a much higher ratio. Part of the reason I always ask that question is because I'm going to be talking to you about things that apply regardless of the platform. There's a chunk in here about WordPress that I'm talking a little bit broader than that. So really quick, this slide is dedicated to my ego. I have a website, I only put it here because I write on accessibility pretty regularly, so adrenvillay.com. And then you can avoid me on Twitter at our brand, that's a-a-r-e-r-i-a, and I recommend you make me do it. I'm here because the other group was able to take me to come here, otherwise I couldn't afford to fly across the ocean to tell you all these lovely, wonderful things. So, right off the bat, some people have probably seen the a-1-1-y hashtag or seen it, who's maybe not on Twitter or elsewhere, and it's not uncommon for people to say, what is that? What is L? Who is L? What does L mean? So real quick, accessibility, a-1-1-y needs accessibility. It's just a new word in there. It's a pretty common technique in some communities where you just remove all the no letters and you're replaced it with a common character that will come. So localization is L10N, internationalization is I-18N. When you see a-1-1-y or a-11-y or alley, it means accessibility in almost all these cases. The thing about accessibility, though, as I've discovered over the years, it typically gets no respects. It's sort of an afterthought of things that people aren't really too interested in. When I had my own company, we were painting the offices, we were going through colors to paint everything, and that nice blue is called online blue. I don't know why they call it that. The ceiling was cyberspace gray in a real high-tech sounding terms. Oh, yeah, we moved out. But accessible beige. So the color of computers for, you know, old IBM computers from the 1980s. That was the color that my partners wanted to paint my office because I did the accessibility stuff and they thought accessible beige.  So these are the things we're going to run through. Some statistics just to give a little bit of grounding. I'm going to fly through those, though. I'm going to talk about this whole concept of being selfish. The technical bits is probably the part I'm going to post just so you know. So statistics right off. These are U.S. This particular slide is U.S. focused because if you haven't figured out by my accent, yes, I'm from the United States. I don't know if that was obvious. I'll just keep talking. So in the U.S., any disability, when we look at the numbers for who has any type of disability, which includes visual hearing, mobility, cognitive, we're looking at in that age range of 21 to 64, 10% of the population. You'll note that at this 75 and up age, it's 50%. Sort of a theme that happens. Worldwide, 285 million people have some sort of vision impairment and 82% of those people living with blindness are 50 and above. There's a bit of an age factor there as well as we see from some of these other stats. Hearing impairments affect 360 million people worldwide. That's disabling hearing loss. That means that they really do need help to get by and say an event like this where you're socializing with a room full of other people who are also socializing, all of whom have more interesting things to say. So 36 million American adults report some degree of hearing loss. Mobility impairments relatively low as you're younger, but they tend to increase. So 5.5% in the 21 to 64 year old age bracket in the U.S. goes up to a third of the population that are 75 and older. Cognitive impairments are always a little bit trickier for people to sort of get their arms around. It includes, this is just some of them, dyslexia, dyscalculia, which is the numbers version of dyslexia to simplify it. Memory issues, distractions, the list goes on and on and on. In the U.S. that number is about 4.3% of the population in my age bracket and then again continues to climb. But one thing I've learned is that showing the stats doesn't really make the case. I show the stats because I want people to understand first and foremost this is a real population of people. If you're more like me, you don't care.  My whole treatise is about being selfish. So that's what I'm here to talk to you about. If you were in Heather Burns's talk earlier today, you might have seen this pyramid and if you weren't, cool, now you get to see it for the first time I guess. So WebAIM is an organization called Web Accessibility in Mind and they have this hierarchy that they see as motivating accessibility change. And when you start off by guilting people, you're not going to be as effective. Punishment means that they've already done something and that just creates a bad relationship afterward. You make it a requirement, they'll do it, but they're not necessarily so interested. If you start to reward people, then they start to pick it up a little bit more. You want to work to get them enlightened and ultimately you want them to be inspired. You want them to just know that it's the right thing to do and feel that something that sets them apart in the product. I again am wired very selfishly so I modified it. I put a star on top of this tree. And it's all about making it about me. So you might have been in some talks already, you've heard people talking about the users, not this guy. So to run through some of these things, getting older affects nearly everybody except those who are fortunate enough to not have to get older, I should really rethink that. So it does carry risks and side effects as I note and it's definitely not for the young as evidenced by how few young people are old. The only thing separating these two couples besides about four feet is probably 30, 40 years. But really they're doing the same thing. They're living the same life. They're both arguing about probably where they're going to go get some food next. I don't know for sure. The only thing separating these two women besides the fact that one of them is using a solar powered piece of technology is probably about 40 years again. They're doing the same thing. They're hanging out, they're reading. Well, she might be tweeting, I don't know. But conceptually they're doing the same thing. The only difference for them is age. Really not that different. Accidents happen to people a lot. I am evidence of that. I could show you the row of scars across my head and all the other things I've broken over the years kind of weird and I might be in violation of the code of conduct. Accidents come in the form of everything like broken limbs, eye injuries, hearing injuries, head trauma, et cetera. If you've ever broken a wrist and tried to use a computer, you realize how quickly, whether you quickly realize how difficult it is to do things like operate the mouse, use the keyboard, close the lid, actually click save instead of reply at the wrong time. Sometimes just having a temporary vision problem means that you lose your depth perception and instead of grabbing the mouse, you end up pushing it off the table. Hilarious. And now that they're all wireless, now you have to go hunting for it, you can't just reel it in. Some people do it as a fashion choice. Some people arguably might start an activity with a cognitive issue, but they definitely end with more issues. That wheel of cheese that they're chasing down a hill, by the way, is a tradition somewhere in this country. You all should know better than I, I hope, because I forgot. Anyway, what's interesting about this is at the bottom of the hill they have a team of ambulances waiting. It's not a function of if somebody gets hurt. After every one of these, somebody walks away temporarily disabled, maybe permanently depending on whether or not they got the cheese. If, like me, you believe that you are invincible and allergic to nothing, then there are other things you have to bear in mind. Multitasking, sunlight can be a great weakness, eating at your desk, not having headphones handy, just not even working in your native language. And I thought my native language was English until I came here, so that's awkward. But this is how I spend a lot of my days. I try not to get a taco filling bits into my keyboard because it's a laptop and you can't just shake it. It's very bad. I like to sit on my patio or on my porch and if you've ever used a phone in the sun or tried to work in the sun, it's really difficult.  Oh, it already ran out. These guys, I think, are professionals. I would like to point out, though, that neither of them has a free hand to actually use the computer. But they brought the tarp. I mean, these guys are on top of it. But this is a function of they're not just in the sun, they're distracted, they're doing other things. And if by chance they had to use email or fill out an online application or sign up for a bank account, you'll know nine times out of ten they're doing it wrong, every keystroke. This guy's my favorite, though. I would like to point out, part of the reason he's my favorite is because his laptop is a typewriter. Solar-powered, baby. Sometimes you find that you're working in a public space because it's the only option you have. I can tell you the Airbnb flat that I have right now is a little too small. So I will probably be working in cafes for the next few days. This is a case where the headphones become really important. He's doing video work. It's very hard to do video work when there's a lot of background noise because, well, you can't hear anything. And maybe you don't want everybody to hear what you're up to anyway. Also, the consideration of having a significant other in bed with you. I work in bed.  This photo is kind of analogous to how I live. I don't live in apartments, but I do live somewhere where I am flanked by motorcycles. And on the weekends, these guys like to have motorcycle duels. They want to show whose motorcycle is louder and throatier. And if I am trying to do any work, that's very much a problem. It also explains why I have closed captions on my television permanently. I never know when they're going to start it up and it's usually during the critical scene of Mighty Morphin Power Rangers. I have been this person in a foreign country trying to look up information about the flight that might have been canceled on a keyboard that has characters I don't recognize, looking at a website that is localized for the region I'm in as opposed to the language I speak. And all of a sudden, I feel like I have a cognitive disability because I don't know what I'm looking at. It makes no sense to me. This happens more often than I think people are really willing to admit. And from my experience just bouncing around Europe and Southeast Asia, when I go into any place that has these public terminals, there are a lot of really confused people sitting at them. They're not locals. They're just confused. Another thing to consider though is that if you're in this room, you probably have some comfort level with technology, which means that when it comes to family events, the holidays, you might be tech support.  I don't like going to my parents' house and changing printer paper and printer cartridges and updating all the software on their machine and doing all the windows checks and reboots galore. I just want to eat the turkey. It's a simple goal. So if you're in a situation where you're always helping other people, you might start to recognize that if the interfaces were a little bit easier, maybe you wouldn't have to spend so much of that time. You could eat turkey. If turkey is a thing here, not so much. Yeah, that's why we left. Anyway, so I'm still going to stick to sort of high level here. I'm going to talk a little bit about user experience models. I've given you sort of the context for Selfish and I'm going to pull it into user stories. I'm not going to spend too much time on this, but is anybody here not familiar with user stories? This is awesome. I don't have to spend 14 minutes on this slide. So I have these really simple user stories that are based on this Selfish model. Let me give you a little bit of context as you're reading that anyway. I have found that when I put together personas and user stories for clients, they often don't understand who that accessible persona is. They're not necessarily invested in it or interested in it. All it does is represent extra work they're going to have to do. And in many organizations, when they are looking at how many personas they have, they're saying, we need to get down to three or four, maybe five on the high end. Who do you think is the first persona to get cut? Jerry, the guy in the wheelchair. Lucy, the one who can't see. Those gone every time. So I have started to fold these selfish concepts into personas, and I'm showing you the user stories first because it's a little bit more digestible. So as a user on a Sunlit patio, I want to be able to read the content and see the controls of a web page. This affects a lot of people. As a user in bed with a sleeping spouse, I want to watch a training video in silence so I can get caught up at work. This is a real use case. This is a real thing that happens. In order to click links, as a user with no elbow room in coach class with a tiny track pad, so you were all on my flight too. I want click areas to be large enough and adequately spaced. As a user distracted by the TV, I want clear headings and labels so that I don't lose my place. This really speaks to my inability to have a good work ethic because I just sit on the couch and watch. For what is worth, there are some personas from the book, A Web for Everyone. There's a free chapter online and these personas are free for you to grab. Sarah Horton and Whitney Cuesenberry wrote this, and the personas are great and they are personas for people with disabilities. I encourage you to go steal them and use them wherever you can. I also encourage you to look at creating a persona. Yeah, that is me. Maybe this isn't as good an example as I was hoping it to be. Am I doing that? Is that better? I'll stand here for a minute. It is not uncommon to be in a situation where the personas, once they're discarded, you're not going to get them back, but what you can do is you can take the persona that might speak to a particular stakeholder, the president, the client relations person, whatever, take that persona where they've already identified with it, and fold in a trait. And maybe the trait is that person travels. It's always on the train. And now you can fold in the fact that there's a mobility impairment. And for another persona, say this one always works in a cafe in the sun and can't always hear because of the noise. And now you've folded in hearing and mobility and maybe visual impairments. So don't necessarily try to build these separate, discrete personas and user stories. Instead, appeal to the inherent selfishness of your clients and build them into the personas and the things that they do into those personas. I've had some reasonably good luck with that. Mostly because they see themselves and they say, yeah, I understand that.  This is the part where I look at my watch because I'm terrible at managing time. And I told the timekeeper not to bother because I'm not going to pay attention anyway. Right? She knows me already. So I'm going to go through some technical bits. Much of the rest of this is about code stuff. I may dwell on a few bits of it, but the nice thing is all of these samples will be out there for you to look at. Use alt text on images. Please, for the love of God. So this is Buffalo Soccer Club. I'm very proud of this. It's an inner city youth soccer program that I co-founded back in Buffalo, New York, where I'm from, by the way. We think it's pretty awesome. I'm not going to bore you too much with it other than the pictures. So this is the page showing, hey, here it is and here's a happy kid playing soccer.  It's strictly decorative. The logo up there does have text behind it because that's important. That's the name of the organization. The other places where there were images that were strictly decorative, there's no alt text behind them. So the notion here is to use alt text, be smart about where you use the alt text so you're not creating two verbose of a page for a screen reader. Can you still make sense of the page without the images? Is any of the content missing, which is a sign that maybe you have some text set in a graphic? That's a problem. Can you still use the site? And is your alt text useful? There's this wonderful chart. Yeah, don't worry. You don't have to. But there's this chart that later on you can look at and it's just a way to get you familiar with those steps on how to decide what alt text to use and what is appropriate. Hyperlinks. This is an example of a page that I can never tell what is a link on here. I never know which element on this page is a link. Some simple tips for hyperlinks and this is really basic stuff but incredibly useful. Avoid the click here, the more, the link tos, the key reading, et cetera. Avoid all caps. Maybe don't make a URL a link because a screen reader is going to announce the entire thing. emoticons are probably worth avoiding, not just because they have cultural cues embedded in them, but a lot of screen readers can't announce them anyway. Maybe one people before you open a new window. Maybe inform them that they're going to download something and that it's a 200 meg PDF because I don't know why people do that but they do. Make sure the links are underlined and obvious. Make sure that if your image is a link that there's alt text behind it that's still valuable and useful. Make sure the link text is consistent. If you're going to keep linking to the same resource like that 200 megabyte PDF that you're all suddenly fascinated with, at least every time you link to it and mention, oh yeah, this is that 200 megabyte PDF, you should stop clicking. Use link underlines. Color alone is inadequate. I have it showing in the, through some different types of color blindness here, but what's most important is that orange is the color for links. Orange is also their call out color. Hey, look at this thing. So I never know what is a link on the Verge site because the same color is used to highlight stuff. You're not Google. I don't care how awesome your site is. I don't care who you think you are. You're not Google. Google can get away with it because everybody understands the layout of the search results and we all know what we're getting. They know the layout. They're used to it. There's all this lovely stuff in the web content accessibility guidelines that coaches you and what really you need to know is just make sure you leave the link underlines in place for everybody's benefit. Use focus styles. I am tabbing through the Virgin America page right now. All you can see is that this is updating. I have no idea where I am. This is for anybody who uses a keyboard primarily instead of a mouse. Oh, I must have hit something. I still don't know where I am. Use focus styles whenever possible. If you remove link underlines, you really need them. Anytime you see focus outline none in the CSS, just delete it. Just deleting that alone makes your website probably a lot more accessible. And it's very simple to test. Just use the tab key. Wherever you have a hover style, make sure you have a focus style. Color contrast is important. Same page we saw before, but this is looking at it through three different types of color blindness. Tritonopia, Protonopia, Deuteronopia. It's important that there's enough contrast because those colors aren't always going to be discernible on their own. And I have links to all these tools so you can grab those after I've finished talking and you've taken an app and then you've downloaded my slides. Use the label element. Here's an example really easy to test. If I click that field, the focus should go into that input. I'm sorry, if I click that label, the focus should go into that text input field. It's really simple to do. All you have to do is match the four attribute on the label with the ID on the element that you're pairing it to. That's it. Simple to test. Make sure you do it with radio buttons and checkboxes because if you don't, holy crap, is that going to be difficult? Use HTML5. Great way to be accessible. Just use HTML5. Really straightforward. Here's a layout that probably looks familiar to you. Really simple and really basic, but you probably already know what those elements are on the page. And there are HTML elements that speak to those design elements. We've got the header, which has a roll of banner already built in. The navigation, which maybe lives up top for you over on the other side, might live within the header. The main content, the footer, there's a search form, an aside, et cetera. Those are already built in. Here is the responsive version of it. For all values of responsive, that mean narrow viewport. Because we know that, yeah. So same thing. Familiar layout, header, nav, form, the roll search, the main, aside, footer. Just use the HTML5. You'll be in a much better place. Bear in mind that the main, you should only use one of those per page. Because screen reader users can jump right to the main content of your area. And if you have more than one main content area, then you don't have a main content area. Use your headings wisely. So this incredibly boring blog post on my site, if you just navigate by headings, those headings show the entire structure of the article. And there are users who navigate by headings and who listen to just the headings of a page to understand the structure. So don't skip levels. Start with H1. Should probably match the title of the page. Just use one H1. Make sure you're nesting them appropriately. If you've seen anybody who says that the document outline algorithm says you can use all H1s, I'm sorry, that's wrong. It's documented in the HTML specification. It's been written about many times. Don't use an all H1 approach. Every time you use a new section or article, it should get a heading, but it should not be an H1. And if you think it's going to affect your search engine optimization, don't worry about that. Google refuses to give direct answers, but Google has made it very clear that there is no outline algorithm. Using a button versus an anchor versus an input element, you can style them all to look exactly the same way. Really easy to do, right? Yeah, well, don't. Consider using the right element for the task at hand. Right off the bat, don't use a div or a span. If you find yourself putting an on click on a div or a span, stop. Think about what you're doing. Cry a little. We'll get through it. If it takes me to another web page address, including an anchor further down the page, use the ahref. If it's taking me, if it's only doing something on the page, it's not moving me off the page, it's expanding, collapsing, hiding, showing, use a button element. If you're submitting a form, input type submit, I prefer over the button type submit, only because I find that there are fewer style conflicts if people are using the input type submit. I have an article about this that also talks about the key handlers, and what the effects of those are. Don't use a tab index of greater than zero. If you have a captcha on your page, this is just a silly example. As soon as you start tabbing, it jumps right to the captcha because Google's old captcha had a tab index. One, two, three, four. I couldn't even get to the skip navigation link because it jumped me right to the bottom of the page. And what's funny is that I filed a bug with a digital Gov team and they insisted I was wrong and they could not reproduce the issue of keyboard. It's funny how you learn that stuff. A tab index of negative one is great if you don't want it to have keyboard focus, but you want to use script to put focus on it at some point, like a close button on a modal, for example. A tab index of zero at least puts it into the focus order. So if you have a div with a non-click and a tab index zero, stop. Go back to slides. But tab indexes of zero is useful for things that do become interactive for whatever reason. Just don't ever do tab index of one or greater. It is worth noting there are places where tab index zero is very useful. I have seen the grid, literally just a data table that has either scrolling content or has content that only appears on hover. You may have content on your web page that is in a little scrolly box, for example. The keyboard user can't get into that and make it scroll. So putting a tab index of zero on that means that it'll get focus. You can give it a roll as well if you want. You can give it an aria label if you want. But more importantly, giving it that tab index of zero means that a user with just a keyboard can tab into it and then can use the arrow keys to scroll up and down and experience the content that was otherwise missing. Please do set the lang attribute on your HTML element. I have a whole talk on this, and I talk about all the wonderful benefits for a number of fields and everything else, but probably the thing that's most valuable to know is that screen readers in particular really, really benefit from this because they will say things the appropriate way. In my other talk, I have the lyrics of Nick Cave songs that I have read out in German and French, and they're funnier that way, but we're not going to do that here. Source order matters. It's very easy today to blow up the way that we tab through content just by using floats and absolute positioning. Be aware that Flexbox and Now Grid can also screw with things. It doesn't mean you've done anything wrong, but just know by tabbing through the page what's going to happen when you start to reorder the content. Definitely don't disable Zoom. Definitely don't do that. Otherwise you'd never know that Bill Murray thinks you're awesome. Enhance. So it's not just for mobile users, but for all users. Just make sure that you don't ever have a user scalable know. Get rid of that. If you're interested in supporting Windows mobile phones, the MS Viewport will help you address that as well. The nice thing is most mobile devices now override the Zoom settings, so you can still Zoom no matter what happens. Avoid infinite scroll wherever possible, he says, thinking about the WordPress themes page. But I use this as an example. Avoid infinite scroll. It makes it impossible to access some of the content on a page, such as the footer or maybe even sidebar links. It ruins the back button. Sharing a URL to a specific place in those results is impossible. You can't just jump into a link and go back and get to where you were. And less powerful computers and devices and assistive technology will just choke. And that's not fun for anybody. Use captions and subtitles wherever possible. Nomorkraptions.com is a great resource for pulling in captions that are auto-generated. Yes, that says well so long to his Viagra. Don't let Google auto-caption because they will be terrible. But if you let Google auto-caption, you can use Nomorkraptions, pull in all that stuff that's already time-stamped and fix it, which might involve using the word Viagra a lot more. Remember, though, everybody uses captions and subtitles. Regardless of the circumstances, try to include the audio description as well, like he dropped the microphone, everybody laughed, and the speaker identification whenever possible. Yeah, more there. Some of you might have heard of ARIA, accessible, rich internet applications. You've probably seen people ask questions about ARIA all the time. Don't stress, unless you're building some really complex, really novel user interface elements, you probably don't need ARIA. ARIA has some simple rules. Basically, don't override. HTML already does a lot of great stuff. Don't override it. Maybe don't change the stuff that's there, so don't make a heading into a button. Make sure that they're still usable by the keyboard. Pretty straightforward. You wouldn't want to use ARIA to make something more accessible and then break it for keyboard users. Don't use role presentation or ARIA hidden true on something that needs to get focused because now it just disappears for some users. And remember that all interactive elements must have an accessible name. They must have some piece of text associated with them that says what the control is, ideally what it is and what it does, and in many cases what its current state is, toggled, on, off, blue, angry. So I'd mentioned the div with the on click. If you want to make that accessible, you'd have to add the tab index of zero, and then you need to throw on the key press because it has to respond to a keyboard, and then you want to make sure you give it a role of button so that it's announced properly. So what you're doing is you're creating... This doesn't even include all the code. There's a lot of JavaScript that has to support all the keyboard commands as well. Just to turn a div into a button when I could just do that. I mean, it really is that simple. It really is not that hard to do. Conveniently, WordPress has decided to go all in on WCAG. I still don't know if that's the way you're supposed to say it, but that's the way I see it. There's this lovely announcement from the state of Word 2015. She's just going to kill me after this. Anyway, what's hilarious about this is there are no transcripts for this video, but you can get in there and see him talk about how they are moving forward with this, and we are fortunate enough to have Rihanna and our audience today. I think this is really, really important. All new or updated code released into WordPress core and bundled themes must conform with WCAG 2.0, level AA. That's important because level AA is what people are using when it comes to government, when it comes to lawsuits, when it comes to a lot of business's best practices. It has just become the de facto standard. All these great notes on that. I'm going to leave these things with you guys. The accessibility ready tag is a great way to go grab some pre-built themes and not have to stress about the accessibility because it's already there. I think there are 123 as of a few days ago. The nice thing is it keeps growing. Yet more notes. Oh, by the way, Rihanna won the Heroes of Accessibility Award. I thought that was awesome. Good for you. Absolutely. She should be doing this more than me. Oh, look, infinite scroll again. There are some plugins already made. Joe Doulson wrote these three. I have links to them. I'm going to wrap this up, which will leave me about 12 seconds for questions in a moment. But it's going to take me three minutes just to explain to you I need 12 seconds. So here's the general message. They're trying to convey to you in addition to just being a selfish git like I am. Supporting accessibility now is going to serve future you. I showed you those stats before about how people accrue disabilities as they age or do dumb things, which they do over time. So supporting accessibility now also helps the injured version of you or the encumbered version of you. By getting younger developers to buy into it now is going to help future you if you are teaching them well because you're not always going to be the one who is able to do this, whether it be code it, drive it, create a requirement, write it into contracts. Start doing it now because in a few years you're not going to be able to get people to build this stuff that's going to benefit you. So this is sort of future-proofing your life. This is often held up as a wonderful example of how integrating accessibility into design can be great and look good and be useful for everybody. This is a death trap.  I imagine there's a pit of alligators off the shot here. This is terrible. So you have to be careful when you're trying to integrate these things. Don't just try to make it look good but actually spend a little bit of time putting somebody in a wheelchair on that ramp and if they don't die, listen to what feedback they give you. Accessibility is not a checklist. You can't just say we built a ramp and walk away from it. Further, it's something you have to maintain. So this is a wonderful example of a ramp that goes into a drug store that a friend of mine couldn't get into because they put the trees on the ramp. They lifted the trees because it snowed and put them on the ramp and he wheeled up there and that's much more polite than what he said in real life. It's not just a checklist. It's also not something that you can do once and walk away from. It's an ongoing process. It's something you have to maintain and usually the easiest way to maintain it is to not stress about it. Don't overwrite it. Don't build new things into it without understanding their impact. If you've got good headings everywhere, good. You're in good shape. You probably don't need to stress. So it's not a checklist. It's an ongoing process. Be prepared to internalize that and get on your own. My slides will be available, provided I can get good Wi-Fi and I have how long for questions? Two minutes. I won't probably need it. So do we have any questions? No? Really? Do you have a view on access keys at all? I don't know. Access keys? So the general... That's a really big question. So I'm going to try and really simple. Access keys are awesome in the right context. The problem is the people who benefit from them are often using tools that intercept those keys and they become very problematic. There is a group of people who feel very strongly that access keys have value. The trick is figuring out how to make sure those access keys are presented in a way that people who use assistive technology can still benefit without breaking the technology they're using. I don't think they have value to them. I don't think that they are workable with the current technologies that we have today. Hope that was quick enough. Other questions? There's no way I answered everything. Is everybody asleep? Alright. Old caps, don't do old caps. That's obviously true for larger blocks of text. Because it's difficult for anyone to read large blocks of old caps text. For example, Google Material Designs recommends old caps for buttons. All caps for buttons? No. And here's the thing about all caps. A screen reader will typically announce every letter. Depending on the user's verbosity settings you might put something in all caps and the screen reader is going to say S U B M I because it thinks it's an acronym or an abbreviation. I always encourage people to avoid all caps. In headings you can get away with it stylistically if you're using just CSS, but I still always caution people to avoid all caps whenever possible, particularly on user interface controls because that's where the problem manifests because it can prevent people from actually completing a task. Related to that, screen readers, do they interpret text transform uppercase too? The screen reader bases text transform off of how the browser passes it. So the short answer is it depends. It depends on the screen reader, the version, the browser, the version of the browser, how the CSS was put in there. So it's not a really simple answer, it's variable. And that's where testing is important.  But you were very polite about it. Very polite. Okay, that's it. Thank you.


Civilians must stay in their homes. Civilians must stay away from walls. Civilians must stay silent. This is a national security message from the SCP Foundation. A dangerous humanoid anomaly called SCP-106 has escaped from containment. This anomaly is hostile and lethal and you must follow the safety steps outlined. If you do this, you will be safe from SCP-106. SCP-106 can walk through and on walls, floors and ceilings. It can also produce a corrosive effect, which can rot, rust or otherwise destroy anything it touches. SCP-106 can also access and move through a pocket dimension. These abilities make SCP-106 extremely dangerous and at no point should you attempt to fight the anomaly. Instead, follow the safety orders and remain hidden. The SCP Foundation will re-contain SCP-106. Thank you for cooperating. SCP Foundation. Secure. Contain. Protect.


Hi. Hi. Good. Good. Well, my name is Evgenia Schmacher. I work at Mirantis. And I have Scott here. He's from PayPal and I'm going to pass the ball to him. So today we are going to talk about compliance. And I see quite a few people here. I hope all of you guys just decided to have a nap after the coffee break because compliance is boring, you know. Everybody knows about it. We'll try to make it more fun, but I don't promise anything. Well, as I said, I'm a business analyst at Mirantis. Actually, I'm not that familiar. Like, I'm not a very open-stack person. Like, I'm not a developer. And at the same time, I'm not a hacker. I'm not the person who knows how to make penetration tasting or whatever. But still, I spent a couple of years working at the security company. And I know what compliance is and actually that the standards, different types of standards like industry standards, government standards, they are a good source of business requirements for customers that we usually have. It doesn't matter which customers, but for our case, it's open-stack customers. Well, when it comes to compliance, and when I started to talk to different open-stack people and I asked them, what about compliance? What are you doing about compliance? The most common answer I heard was, okay, and what is compliance? Well, here you can see the pretty, like, I just copy and paste some information from Wikipedia. So it's very long and not very interesting description of what compliance is. But don't read it, please. I think you have already read, okay? But anyway, what I would like to say is just compliance doesn't mean security. And it's very important to say to people that people understand it. Okay, now I see that there is a place where I can actually see my slides. Good. Yeah, so actually, compliance is not the security. And being compliant doesn't mean that you are secured and being secure doesn't mean that you are compliant. And when it comes to, when we talk to, like, open-stack developers, open-stack developers, all of these people, they are very technical. And you guys, I'm pretty sure you are very technical. And what you can understand is security. But when it comes to different standards and papers and, like, 200-page documents, well, it's very boring. You can become sleepy. It's okay, actually. But still, it's very important to understand what compliance is and why we as, like, open-stack community should think about it. Actually, if you look at the standards, like, different guidelines, regulations, et cetera, what we will find that most all of them are about information, about its availability, confidentiality, and integrity. And only the part which is about confidentiality is more about security. Other parts, they cover all the different topics of the whole, like, your customer system. And, of course, for people who write code, it's not that obvious that it is important, but it is important for companies. And as long as, like, open-stack is now pretty mature and we go enterprise, we build private and public clouds for banks, like Wells Fargo, we build, we deploy open-stack clouds in different, like, the U.S. government organization. What we should think about is, like, that this cloud, they should follow the rules this organization have, organizations have. And these rules are different types of standards. Well, let's take a look at the, like, the whole enterprise ecosystem and the open-stack in it. So as you can see, we have, like, physical facilities, we have data, we have open-stack, we have people, we have business processes, and this whole ecosystem, it should follow the regulations, different types of regulation, which means that, like, open-stack as a part of this ecosystem must follow these regulations as well. So, practically, if you look at the situation the way we have open-stack cloud deployed, and now our customer owns it, so he or she is the one who is responsible for the whole compliance. But we, as the people who develop open-stack, who build open-stack clouds, we are responsible to deliver the product, the solution which can be compliant in a very easy and, like, painless way. Here I decided, like, to show you, like, an example, that it doesn't matter, either you build, you're building, like, infrastructure as a service, or platform as a service, or software as a service, you see that the open-stack is that layer that, alongside this processing and physical facilities, all these three layers, they are on your side as a cloud builder, which means, which means when you come to service provider or to a kind of private company where, and you build a small private cloud for them, you are the one who should, like, do all your best to make all these three layers as much compliant as possible. It doesn't mean that the whole, like, ecosystem will be compliant. No, these people, they have things to do on their side, and Scott is going to tell you a lot of things about it. But, anyway, this is how things work. This is why we should think about it. Well, it was, I talked about, like, standards. It was a kind of justification part. I tried to, like, convince you that standards are important and compliance is not boring. I know I was boring, but it's okay. Now, let's move to the standards. And here I have, like, a very short list of standards that we use, I think all of us, we know. Like, PCI-DS says it's a payment cart industry standard. HIPAA is a healthcare standard. We have SOCs. We have some very specific government standards here, like FISMA FedRAMP. They are not more, like, standards, but, like, procedures, programs, guidelines for OD, like, for things that you should be done in order to be certified. We have ISO, very, like, very basic, but at the same time, very important standard. We have NIST.  These particular standards are about, like, security controls, but there are plenty of others that some companies, they should follow. It depends. It depends on the, on the business model. The company follows. It depends. Either it's a bank or a private company or a public company or government organization or a science institution. Doesn't matter, but a lot of standards. And the second question that comes, like, to everyone's mind, why should open stackers think about all these standards? And how they could know about all these standards? They're just, like, people who write code, who deploy clouds. They know a lot about virtualization. How should they know that they need to read, like, SOCs or whatever? And how should they know what they should do to be compliant with it? Well, good thing, good, like, good news here is that all these standards, like, almost all standards, they have pretty, like, typical structure.  And actually, there is a tendency in the community, in, like, compliance community, just to take all these controls and have, like, metrics, have, like, a set of controls that covers, like, all different types of standards. And the best news here is that, actually, the job, specifically for cloud standards, is done already by, by CSA. And actually, they have around, like, I think, 140 controls in one place, in one matrix. And they cover PCI-DSS, hip bind, all other different standards that are usually important for our customers, like, for different companies and for open-stack customers, of course. So, and if you take a look at the, I think you can see, if you take a look at the slide, you will see that in control specification is written something really generic, like, security mechanisms shall be implemented to prevent data leakage. So nothing specific. And that's true about almost all the standards, like, here's PCI-DSS. Like, all these standards, they have requirements and controls. They are pretty generic. You won't find words, like, open-stack, cloud, I don't know, cloud, like, KVM, or something, like, super specific. This is how they were designed. And probably, you know what standards, like, your open-stack cloud is a part of organization ecosystem should be compliant with, but you don't know how to do it. And maybe, like, two or three years ago, nobody knew it. But now there is a tendency that different organizations like PCI-Conceal and NIST, they are working on it and they implemented a bunch of guidelines on how to map those requirements from these generic standards to cloud infrastructure. They are working hard, but still, you know, like, if you take a look at PCI-DSS cloud guidelines, what they say, oh, please don't store process or transmit payment card data in the cloud, because they don't know how to deal with it. And actually, there are some technical people who know how cloud works. So they can say, like, it's okay to store and transmit data in the cloud. You just need to know how and to be very, like, very, very smart to do it, yeah? Well, anyway, if you take a look at another PCI-DSS guidelines, you'll find more, like, specific information, which is pretty useful. Now we see words like VM images and virtual system, which is very helpful. Still, nothing about OpenStack. And actually, you won't find, like, anything very specific about OpenStack. That's why, you know, we have this kind of really interesting situation. We have OpenStack is pretty mature now that we know that clouds we're building, they must be compliant with different standards. Different organizations that publish those standards, they understand that there is a cloud, clouds, and there is a tendency for different companies to go cloud, to go up. And now we need to work, like, in both directions, like, like PCI Council, they publish some kind of cloud guidelines. And what we need to do now is, like, to hear, like, the OpenStack community, we need to take those guidelines, take our expertise, and to create a bunch of guidelines for OpenStack clouds to be compliant. How to build a cloud that can be compliant, that can be secured, that can follow the rules, like, different types of rules. And as you probably know, OpenStack has an OpenStack security group. They published a really nice document, OpenStack security guide with a section about compliance. It's very interesting, it's not that, like, complete kind of limited, but guys, they are really working on it. And Scott, one of the guys who's going to, he's going to say a couple of words about it, I believe, but he's the one who's going to contribute there. And also, I know different companies, they are struggling, like, with compliance issues, so they kind of have, they invented their own way how to be compliant. Like, we at Mirages, we did some stuff for PCI compliance. And some people from our team, they presented the previous summit at Hong Kong. So, here you will find the link to this presentation, so feel free to see it and to watch the slides. So, and practically, actually, like, I think that's it, yeah. My talk was more kind of educational and just to say that, guys, like, clouds, OpenStack clouds must be compliant.  And as long as these standards go on the way to cloud, OpenStack as a cloud technology, need to go towards the compliance. And now I'm going to pass the ball to Scott and he will provide you with some really nice use cases. So, thank you. No. Hello, hello, hello. There we go. All right. So, Scott Carlson, I work at PayPal, and I am the cloud security architect for PayPal. One thing that is important as I go into this presentation, a lot of the compliance talks at the past conferences have included a lot of information around what compliance means, like nobody has ever had to do compliance before on infrastructure in a data center. And what I want to make sure everybody understands is compliance means something specific for you. But there are some key things that you need to remember when you take a look at compliance, decide how it sort of fits in your use case. And what's nice is it shares a whole bunch of different sort of common things that apply to OpenStack as well as elsewhere. As you can see from our cool new infographic that we just came out with, we are everywhere. PayPal does business in a lot of markets and a lot of countries. And especially if you look at Asia, the EU, Brazil, the United States, there are compliance requirements for all of these countries, very specific to their country, but many of them share a lot of the exact same underlying sort of foundational elements that are in all of the majority of the standards that she just talked about. When we apply our sort of take a look at our company size, the cloud that we're building has to go across multiple geographies, multiple countries, as well as multiple data centers. So when I look at compliance, when I take a look from the PayPal side, I have to think what kind of things can I do to make sure that my cloud comes out of the gate pretty compliant no matter where I build it. So that's why PayPal has started to focus on a data center that we can define with software. Of course it has physical components like switches and firewalls and routers, all those common things that you need to build a network. But there's some common principles that we want to do out of the gate as we build new Havana based clouds, ice house based clouds to ensure that we at least get these minimum set of criteria out for compliance. Some of the things I think people can read, I won't cover the slide specifically, but common things that apply to most virtualization environments and most clouds that you build include good design principles, templates. What do you do with templates if they're on and they're off? What do you do with common infrastructures to deploy one image everywhere? Other things like scale up, scale down, what do you do when you turn the VM off? All these things people have looked at in the VMware space for a lot of years. So it really doesn't need to be that different with OpenStack. You can really make your brain hurt. If you take a look and you say, oh no, OpenStack is a brand new thing, how in the world am I going to ever make a compliance since there's no NIST document called how to make OpenStack compliant? The thing that we're concerned with at PayPal is yes, we need to be compliant, but we also want to be secure. Securing our customer's information is the most important thing for us and we want you to feel comfortable when you do business with us. So out of the gate, what I think I'll focus on mostly here in terms of the general criteria, and I want to sort of talk to you guys like you've done this before, right? SmartSys admins in the room, people are building clouds, but we're going to focus on PCI2. PCI3 is different enough. It starts to get sort of a little bit more aggressive, but let's start with PCI2 and let's figure out what sort of the minimum set of criteria is. So I think I've broken this down into some basic methodologies as well as common things that should make it more easy for you to think about how do I secure this, how do I make it compliant? The one thing out of the gate, OpenStack has servers in it, right? People know how to secure servers. There are NIST standards for secures. There are CIS standards for servers. There's hardware there, right? People know how to do firmware by now. So take a look at your firmware. Dedicate the hardware to the cloud. Hey, that follows the guidance, right? Don't share workloads of different security zones on your hardware, okay? That's pretty easy to do. You want to do that out of the gate. Follow the guidelines for servers. Hypervisor builds, right? Everybody is wondering how do I put down a cloud layer in my private cloud that's compliant? Well, you know what? People have been doing that for a lot of years. The government started it a long time ago. We have IP tables. We have trusted compute. We have all sorts of different ways that you can do it. But really, it's still just a server. So once you get a build standard, which I think almost every single compliance document you read has, have a build standard that is secure, that you scan with a vulnerability scanner, that you patch every 30 days for critical things, that you keep updated, that you have inventory of. It's pretty much word for word in every single standard. The same applies to OpenStack, security, and compliance. You get that vulnerability scanner and you point it at your OpenStack, and it's going to scan Ubuntu, Red Hat, Debian, whatever you have your cloud running on. And it's very likely that that scanner you pick is going to pick up all of those, you know, mostly known vulnerabilities in your hypervisor that you can pretty easily bake into your image that will go anywhere. There's nothing too specific to the U.S. or to other regions about doing that hypervisor. Some of the things that get a little bit more challenging as you sort of look at your hypervisors, how do you patch management, how do you do configuration management, and password management? With the passwords are easy, right, root, and you rotate them and stuff. Config management and patching is tougher in a cloud space. If you're the cloud provider, which PayPal is both in my case, I'm a private cloud, so I built this cloud in my already PCI certified data center. So in essence, I can take advantage of my company controls around my entire data center. I'm not building a cloud for other people to use, and I don't need to worry about separating the managed service provider space from the tenant space, which if you read a lot of the guidance that's out there right now, it actually says if you're a tenant, just go ask your MSP for a certification statement on this. If you go to people like Amazon, they have eight or 10 documents that you can get now that say how they are PCI compliant at the various infrastructure. So in essence, I provide that for myself by following my common practices. Moving on to the next thing, there's users in OpenStack, just like anything else. You've got to follow the standard things. Don't share passwords. Don't share accounts. Create separate accounts. Use different tenants for everything. Don't use your administrator account to build everything. Rotate your passwords just like you would. What you can't do, which we have argued about this inside of PayPal for a very long time, why can't we just use common things? It's just one data center, why shouldn't we just use one building account to build everything? The reason is because it's very slippery slope to get into a non-compliant space. You create an environment that all of a sudden opens up gaps to anybody getting in to do bad things to your network. So do not break the rules that you wouldn't break if you were deploying physical Unix systems when you're building your cloud portal. I think that's very, very important that you do role-based access, like is enabled now in most of the tools for your users out of the gate because that will make you compliant with just about everything out there again. How do you be secure and compliant? Do the basics first. Let's move up the stack a little bit here. Hypervisor components, right? Again, it's just Linux, right? Harden it like Linux, lock it down. If you tell your auditor who's coming in to do PCI, a HIPAA auditor, whatever, and they say, how have you secured your environment? And you say, I took the NIST standard, and I pulled out the steps in the CIS guide, and I hardened it according to that. And here's my checklist. And then I scanned it against that. The questions pretty much stop outside of, okay, show me a couple of examples and prove it. So don't forget to log it. One thing that's interesting about the hypervisor in a cloud space is how do you separate the management traffic from your guest traffic? There's a lot of different ways to do this. And depending on how you build your infrastructure, you can separate at the NIC level. You can separate at the virtual VXLAN sort of level. You can overlay it. But the important thing is that you design your network in such a way that your management traffic is going to be separate from your tenant traffic if you're going to be in a compliant location. The one thing that you don't want to do, so maybe you can, but you shouldn't in my opinion, is combine it all because the minute you do that, every single management component that you bring into the picture now is in scope to be audited. If you have a credit card workflow flowing through a tenant in your private cloud, but you allow your management traffic to talk to that tenant for some reason, now your entire management control plane is in scope because it touched that cardholder data. As you design this, it's very important to consider what touches what and what can talk to what. Because as we look at PCI DSS3, it basically says the minute you touch cardholder data, that's contagious. And everything that touches that now has to be audited, logged, just like it's the most secure thing. Don't combine security zones, and this is an important one. All of the cloud guidance out there right now essentially says that you shouldn't do this. You probably can now. There's containers, and there's IP tables. You can probably harden your hypervisor enough to have a in scope zone and an out of scope zone on the same piece of hardware. I know that VMware has some good guidance for vShield. I know that no such document exists for KVM today, and that's something that we all need to mature if we want to do this. But as of right now, you will not get any questions if you decide to separate hardware between zones. You'll probably get the question from your management, why do I want to waste that compute? How could I dedicate so much hardware to an in scope zone versus a not in scope zone? And the trick there is just do it at a granular enough level, which in our case is one single physical machine. You put it in the right place. Nobody really cares about wasting machine. If you waste a row or a rack, that's a whole completely different scenario, so make sure you do it at the machine level when you separate. Let's see, auditing. Auditing, auditing, logging, you'll never find a compliance standard that doesn't say log it. So everything you can turn on, turn on when it comes to off events.  I don't know if you use syslog or Splunk or log stash or I don't know, pick your log thing of choice, but put it there and keep it a long time. A lot of these things require seven days, prove it for a year. I know one place that I used to work, my auditor would come in and say, okay, it's August.  I want all the logs from you revoking their access in May from your credit card zone. You haven't till tomorrow. And so my team was able to do that because we had kept it all in one place for a year from all the systems. And so I know when a lot of people are building a cloud to try and get it up, a lot of these off events are not turned on by default. They're just starting to get now, but in the past they weren't. Especially login events to Horizon or who created and deleted a VM. Some of the more interesting use cases that we haven't yet sort of figured out is let's pretend my audit is January to January, right? January to December. And during that time PayPal goes through this Black Friday cycle, right? We build 10,000 VMs in November to handle Black Friday, and then in December we tear them down because Black Friday is over. If I built and destroyed 10,000 VMs, are those VMs still in scope for PCI compliance when my audit happens in January or aren't they? Yes, right? A lot of people are shaking their head, yes. So I have to prove that I created them, got rid of them, and really deleted the data, and then who did it? So these logs are very important that you don't just assume you don't need them because you kind of almost have to assume that your guy is going to ask for them and that you'll have to bring them back up. So don't just get rid of them. Keep them forever. Oh, let's see. So be ready to defend your shared portions. This is sort of common thing. Physical world, we've been doing this a long time, right? People share routers. People share firewalls. You don't really need to buy two firewalls to separate your secure zone from your unsecure zone because that's the point of the thing. But have your diagram ready. Have your decision process. Have your architecture ready. Prove that out. Let's talk about the software for a minute here with OpenStack. You can't really buy something like HP Fortify and say go scan OpenStack and tell me it's compliant. It's mostly Python, right? There's not a whole lot of good Python security scanners out there yet. And what you won't do is you won't get a static code analysis of Python that will tell you that there are bugs in it. This place is maturing pretty quick, and a lot of the OpenStack security group is trying to find ways. A lot of the vendors are coming into this space now, specifically, you know, HP is starting to scan their cloud more. And as people create security as a services around some of these things, you will be able to do this sort of, you know, do code analysis. But in our case, so we check out from trunk and we do basic things like would be expected. But one thing that in Scott's opinion here, my opinion, the community needs to look at this over the next couple of years so that as more and more very large financial companies start to deploy this, there needs to be a very easy way to say yes. In fact, this has been scanned 100 million times by every single tool in the market. The version, you know, let's call it Havana, Havana Core as of August passed all of these tests. Here is the practitioner statement. And we're based on that. And as auditors get better at that, or more aware of it, I guess is what I mean, because not a lot of auditors know cloud, let alone OpenStack right now. And so some of these, you know, cloud security lines, all these things, once they get these statements out there about the software, then they can start to do better safety controls over, oh, this is all open source. I'm scared of open source, right? Because I have no idea what bugs were introduced. So a couple of interesting dangers around just checking out from trunk and applying it to your production cloud, I would say just don't do that. You know, check it out, Q8 all the way through the normal cycle, CICD, I think one of my other colleagues is talking about that at this conference. Some of the other things that you really want to do, specifically around OpenStack, make sure you have an open source advocate in your company who follows the licenses, and we know it's compliant from that point of view. It matters in some countries versus other countries. Make sure you do scan it. Somebody takes a look at the code, however your level of comfort is, so that you can prove, you know, at least some level of diligence there. And one thing that I think is really important to add about the software stack is, right now, I think it's very important that you avoid putting any sort of card holder data or compliance data on your cloud itself. That's what guest VMs and tenants are for. Do not compensate and say, oh, I just am going to put this cool thing at the hypervisor so that I can blow it out. I'm just going to put it in the image so that I can blow it out. Just don't do that. Because, again, you run the risk of bringing everything in scope, which you probably didn't want to do. And if you want to get to the place where you can start to descope some things, you will have just messed yourself up by putting your compliant database on a bare metal image on the same v-line as your hypervisor. All right, so this one is kind of more advice based on the stuff we've talked about. I think we'll call this Scott's opinion for now. Stick with physical components. For now, don't go with virtual components when you talk about in-scope compliance separation. Everybody, I think, in the compliance world auditors, everybody speaks physical components today.  The minute you start to bring in virtual components in, you have to bring in the hypervisor, and you have to bring in the network, and you have to bring in the network design into that conversation. Because if you have the most secure firewall living on the least secure hypervisor, there's no point, because you can just bypass the firewall. It doesn't serve the purpose. There are people who are starting to build architectural blueprints to explain how virtual components are good enough. Vendors who roll their virtual component as an ISO that lives on hardware, you know, that's kind of a physical component at that point, because it doesn't live as a guest on top of OpenStack. But what doesn't exist today is a sort of certified reference architecture for how do I take my HA proxy and my virtual ASA along with my virtual F5, how do I stick them together on one hypervisor and call that a compliant cloud? That doesn't exist today because not enough smart people in the community have certified that there's no way to bypass that. The clouds are still a little, I guess, squishy enough where that sort of between component traffic, intratendent traffic, hypervisor traffic, manager traffic, we're still not sure if it's 100% protected. And I guess, in my opinion, until we know with reasonable level of confidence that it's 100% protected, it makes a lot more sense to just externalize these really important things, especially when you're living in a data center like PayPal, where we do this for a living. And nothing wrong with staying physical for a while. And the same thing applies for physical as virtual, I think I want to say this.  Or your physical load bouncer with a firewall? Hey, Cisco, have you tested your firewall? And they'll say, yeah, here's all of our statements for the last 10 years that we've tested this. If you go ask them to do that the same thing for virtual, I haven't had anybody ready to give me a piece of paper yet today that says they have tested their virtual thing at the same level they have tested their physical thing. And so I'm challenging all my vendors to give me a statement on their virtual thing. And hopefully they all will, so everybody push your vendors to do that with virtual. If we're doing dynamic clouds, we need virtual stuff.  Let's see, last slide here. So basic methodology about data, right? It's car holder data, kind of get interesting. Open stack has some native encryption challenges. There's lots of cool little blueprints for relying on the cloud services to encrypt stuff for you. I don't think we're really ready yet unless you want to be bleeding edge to rely on that to encrypt your really cool stuff. So you should just rely on stuff you do today in physical. Use your HSMs, use your key management, use your crypto, take care of all that stuff yourself. There's nothing wrong with building MySQL on your cloud and encrypting your stuff in it as long as you do it the normal way, like you would on physical infrastructure. Just don't rely on your cloud. In my opinion, it's not ready yet. There's no FIP certification, all those kind of things. It's coming, you know, 18 months, two years, we might be ready. Pay attention to your data. Be responsible for your own data on your cloud. Don't rely on your cloud to control your data for you. And then the last thing about users again, it's very specific that you log who's touching the data, what tenant it's involved in, who has access to it. And if you can, start to implement your edge controls. Some of the sort of in-between tenant things like IDS and data movement and behavior isn't there yet. Some of the hooks in VMware made it there two or three years ago. They're not quite all the way there for KVM yet. But at least around your edge or on your tenant, you're going to want to watch what your users are sending in and out so that we can go from there. So I think that's it. Feel free to tweet me or find me afterwards with questions. I think we just have a few minutes left. If you have a question for either of us, please feel free to come up to a mic and happy to answer them. Maybe you have some, you know, like statements to say about compliance. That would be nice to hear to actually. Or if you disagree, please. Yeah. You know, it's like a really hard topic now for OpenStack. So maybe guys, you have something to say. You're welcome. I might go over here. Yeah. So a question about the physical network components and kind of maintaining a boundary. And so you were making statements that at least I interpreted as, okay, so if you keep stuff out of your hypervisor space and keep it in your cloud space, that's good, your data, keeping that separate and keeping it up there above the hypervisor, if you will. Where do you bring in your physical network components without having had some sort of a virtual networking component that just kind of naturally lives within the hypervisor as far as separating out your tenants and things of that nature? Yeah. So I think the way that I'll answer that is in a standard layer three design, right, the default gateway or the route out is through your firewall. So as long as you have different layer three spaces in your in-scope and out-of-scope space and you make, allow them to talk to each other through that firewall, the out-of-scope device, then that's where the physical component comes in.  Everything over here is out-of-scope and the only way to talk to them is through that firewall. Okay. So we have a single user that instantiates all our VMs, but we control access to that pretty heavily. Can you talk more about the weaknesses of that and, you know, I mean, we need to tear everything out. The weaknesses of a single user doing things. Of course, there's lots of it depends in the answer. If your company has a build team that is the team that builds things, you can usually compensate for that with process and pass your compliance audit. Is sharing an account amongst people that you have to walk around with a post it's secure? Absolutely not. And that, I think, is the difference in this thing. You can for sure pass compliance because you have a procedure and a process to manage this and you know who does it. But you can't prove who did it because it's Cloud Builder. You don't know if it's John, Fred or Bob. So you're not necessarily secure. Right. But we're logging who has access to the Cloud Builder and like whenever they instantiate a VM from the Cloud Builder, that gets logged. So their source IP address on your net at internal network? Their username. But didn't you just say you're sharing the same account? Yes. So the in the open stack world, it's a single account, but we have an access system that lives above that. Okay. Who has access to that system.  If your back end demon account is the one that runs off and does things, it's sort of just like using HTTPD, Tivoli, TSM. Those use common accounts to go do things. And as long as that's abstract enough and your password isn't baked into the files, you know, clear text like in some versions of Essex and whatnot, you're pretty okay there. As long as you're RBAC on the front controls that. Scott's opinion, I'm not an auditor. Over here. Most of the compliance require you to tie to a particular release and patch. Now, given the fact that open stack is a open source product, right? And given the fact that it's not compliant. That's a vendor. How do you make sure that you're tied to a particular, I'm talking about standards like 5th 140 and so on, right? How do you make sure that you are tied to a particular patch and a release and you actually certify that patch and release for, because when the patch changes, you need to re-certify. You know what I mean? Yeah. So I guess the way I would answer that as I would say, you need to build your own snapshot methodology for your own internal release management versioning. If you check out once a month or even daily, right? You're probably not going to release them into production daily because it's just too scary. So you're going to want a snapshot at your own, you know, company 1.1.1 is my release candidate, which is Grizzly, August 14th, right? If you bake that and call that a version, I believe it also complies because it is open source and you versioned it yourself and you're tracking it like it's a real version. If you then, you know, put that in an RPM and MD5 it, then it's a real version. It's just controlled by you, just like you wrote it in-house. And so that's how I would answer that. Thank you. Yeah. One more over here, I think, and we're done. Go into your comment earlier about using Linux containers and IP tables. I worked for Oracle in Solaris. We recently worked with Coalfire to help provide some guidance for separation of PCI DSS versus non and using Solaris Zones. And they were very comfortable with that. We've written up in a white paper. So the fact that we've got that, you should be able to use the same thing for the MD who wants to deploy Linux containers because they're similar architecture. And it is all about saying, you know, there's layers in here. In actual fact, something like Linux containers or Solaris Zones are actually more secure in some ways than running in, you know, a tight one hypervisor. Got less of a surface and you can point to more things and show the auditor. It's actually locked down even tighter. Yeah. I appreciate that comment because you did it the right way. You came up with a roadmap, a white paper that showed how it was secure and you can prove it on the back end. And so if the community at large does that with all these components, then I think we're in a good space because people can just follow it for whatever the thing is. So if MD wants to try and do the same thing for Linux containers, that would be great. Solaris Cold Fire White Paper, PCI-DSS, you'll find it. And there's enough information in there to translate it over to them. Solaris Cold Fire? Cold Fire. So Cold Fire was the QSA that we worked with. Got it. Sounds good. Guys, everybody, thanks very much. Appreciate your time. Thank you, guys.


Welcome to Toffy TV, it's the matri action ever nil Manchester United 3 at Godderson Park. Four performance for me. Some people will be pleased with it, that's up to them. I thought, to be honest, I thought it was a gamut throughout in terms of performance. I thought they were okay, they were decent in the first half, I thought they were awful in the second half. Obviously there was a lot of focus beforehand on the protests. It was very, very noisy, a kick-off time, and just before kick-off, Evertonians making their voices heard, making their feelings known. But the disappointing thing for me was, I thought we'd come out with fire and brimstone in the opening. Two or three minutes and we didn't. We just let Manchester United get on the ball and we stood off them and tried to put Membia in the ball and we were undone in the first couple of minutes. We're probably the goal of the season, let's have it right. Good ball across, I think it was Rashford down the right but it across and Garnatio with an unbelievable overhead kick. It was, it was probably one of the best goals I've seen live. It was unbelievable, right in the top corner, nothing Jordan Pickford could do about it. I hadn't watched it again. I could argue that someone like Ashley Young should have been closer to him, but he wasn't really close to him all night. So why would he have been then? But it was a brilliant goal, absolutely worthy of a goal and not what we needed. And it did knock the stuff in a little bit out of us, you know, there was a thing on 10 minutes. Everybody joined in holding the cards up and stuff. Everton had more than enough chances in that first half to go in with a command and lead. United offered nothing going forward in the first half at all really after that wonder goal. And Everton had chances from moments really. I thought we, we were too passive at times and allowed them to have the ball, but we defended really well in the first 45 minutes so they didn't have much. We had chances of our own, I mean. Abdelhaid y corei, 89 yards out, has to score. Dominic Calvert-Lewins had two headers. One he was on his own, he's headed it over. The other one is a header. Unfortunately for us straight out on nine. Dwight McNeill, I will laugh at what he did again, but I cannot believe sitting here, how the ball broke to him and the keeper was on the floor almost. I was managed to hit on Anna instead of absolutely smashing it in. And those moments came and went and we went in. The goal behind at half time and you're hoping for the reaction. I was hoping for the reaction in that second half. I thought the manager will get them fired up. And I was quite confident we might get something at half time. I think I was thinking the fans, it'll be loud against second half.  I mean, I have to talk about the referee in the first half. He was utterly atrocious. If the Premier League were trying to get away from the corruption shots, then having this referee rep perform the way he did was not the way to do it. It just seemed to reiterate what Evertonians were moaning and fuming about. His performance was atrocious.  But then two minutes later, there's the same challenge on Ashley Young by United player, no booking. Garnatio goes in, stood high, catch his young, no booking. He kicked the Bruno Fernandez, kicked the ball away twice, no booking. The court then gets booked for saying how wasn't he booked. And it was that sort of performance from him. He was diabolical, utterly diabolical. But we came out second half and we were just too passive. We were too passive. There was no, I don't know what was said at halftime by the management team, but it looked as if they'd said, just sit back and don't press and don't get in the faces, which was the opposite of what we needed to do, lest there was someone to put some sleeping tablet or something in the cup to tea because we come out looking lethargic, dosy. And we just couldn't get into it and United then, on a rare breakaway, get a penalty. And it's that man Ashley Young again at the centre of it, and he can seize the penalty. The referee booked Antony Marshall first for diving. I'll be honest from where I was. I thought, I didn't think it was a dive. I said, that's the referee on an army, he didn't dive. So the hope was he was just outside the penalty area, obviously via your look to it. And the referee went over to the monitor. And I seen her on the screen in front of me. There's contact. Does he run in to Ashley Young? I don't know. It's a difficult one. I'd have to continue to say it, but Young leaves a photo, trails a photo. Catches Antony Marshall. The referee goes to the screen and he's at the screen for some time. And you know when they go. I mean, Sean Dyche did say this the other week. I think it was after the dive. When they go to the screen, it's a penalty. There's no point. There's no point going on and no expecting any other outcome. They're not strong enough as referees to give to say now I'm sticking with me on fielding. Of course, they don't the bottle jobs and they just get told what to do. So why go to the screen? The ARs are just going into a penalty mate. Give it.  They go over and they say, oh, we've got to look at this and see whether it's a penalty. You know what the outcome is. You know what the outcome. I've seen one, one since VA AR coming, coming wherever and have been given. So it was Chris Cavana, I think I am feel. And he gave a penalty and they obviously tried to talk him out of it. And he went over and he shook his head as if to say to penalty. And he was at the screen for about 10 seconds and came back with the original decision. Most of them get told to go to the screen because they told what to do. So let's not go to the screen. Take away the pantomime and go into the screen and just say, Premier League chiefs have said this is the result they want or whatever. Because it's just, it's so annoying because you know what's coming. So why waste the time? If you went to the screen for all the big decisions, you go, well, this is what they do now, but they don't.  Marcus Rashford dispatched it brilliantly into the roof of the net. And that was it then Manchester United didn't have to go up a gear at all. He just kept us on arm's length. We turned in a performance in that second half. That reminded me of the looting game. We didn't have any idea what we were doing other than just hitting the ball in the air. And it's awful. You know what, a lot of players today for me were way, way, way below the level that you have to be at in the Premier League. Way below it. Maybe, maybe Jara Pranthwaith don't know right. Maybe Michel Encol didn't stop and the rest of them were poor. And we've ended up conceding the third goal, which was so easy. It was untrue. Anthony Martiali, who doesn't seem to score against anybody else, but never done. Got played in. Went through, dinked it over Jordan Pickford for 3-0. And that was it, really. United might have added more if the final ball would have been better. Everton had a little bit of a go near the end, Michel Encol hit the crossbar. There was one where I don't even know how the ball stayed out of the net. We were on the goal line practically with it, and it didn't go in. Yousef Tumiti got brought on, late on for Dom, flash one wide, good strike from him. And that was it, really. It was a second half performance I found unacceptable from the levels that Everton had been playing at. And we were well beaten in the end by United. They don't beat many teams 3-0, and I doubt they will have an easier away performance than what they had in that second 45 today. But we should have been probably 3-1 at halftime. If the manager haven't listened to what the manager said, but I'm sure he'll mention XG, Everton had the better XG. You can't miss chances. You can't miss all good opportunities in the Premier League, and that's what we did when we were punished. We had to dust ourselves down, hope that Beto's fit next weekend in the squad. Sheamus was back on the bench, that was good news. I know we go to Forrest and that's a huge game now.  But we go to Forrest next weekend, it's an opportunity to put it right, take our chances. And we are good away from home, so that gives me a little bit more confidence. It's not a match, it's give us a brand tweet. Like I said, I don't think anyone will be happy with how he played today, but let's give it to Jarrett Brandtweight. There you go, let me know what you think in the comments section below. See you later.