Hi I'm Matt Amarosa and I want to talk to you now about security policy. It turns out that every organization needs to have a set of rules that reflect their intent with respect to security in the organization. And yes, some of the things may not be pure security, there might be some acceptable use type things like, should people be allow on Facebook? Is that a security thing? Nah, it may just be more of a management decision about what employees should be doing or not doing. But for the most part, security policies are going to reflect your position from a security prospective about what you want to allow inbound or outbound. Now I wish I could tell you that there was this incredible technical basis for how you do a perfect policy. And you follow these engineering steps as if you were building a bridge or something, and you come to some very clean set of decisions around your policy rules. Nothing could be further from the truth. The reality is that security policies typically are pretty ad hoc. And they're made by committee and they're hit and miss, and trial and error and up. At least the good news is the way they're laid out is usually pretty clear like usually you'll have a row for inbound, a row for outbound, and then columns for each of the types of services. Here on the screen, I'm showing you inbound and outbound for web services, email services, remote access, and there might be 500 others or five others depending on how your business is set up. Now you have to decide, do you want to allow inbound web services, yes or no? Do you see how that's a decision? Management teams, owners of businesses, the owner of a home, the administrator at your school, whatever, you have to decide, what do you want to allow? And you might say, I only want to allow inbound browsers to hit our corporate website. I don't want all the students in my school setting up web servers. What's that based on? It's based on a threat model in your mind, the decision you made that reflects the purpose of a school. You don't want every kid running web servers. If you were running a web hosting complex it'd be different. You'd never have a rule that says, inbound web services only go here. Your router might be servicing a bunch of companies that you're providing web hosting for. So you have to let it go to all the different web hosts that the packet is pointing to, do you follow? So there's no hard and fast rule, and you establish the policies that ultimately will be implemented in your packet filter firewall. Now let me restate that because that's important. Your policy definitions will lay out requirements and intent. Your packet filter and your firewalls which we'll talk about in subsequent discussions, they implement the policy. There's definition and implementation, you hope that they match. Not always the case, sometimes you could have intent and not realize that your firewall implementation doesn't accurately reflect or implement the policy decisions you made as an organization. So look, if you're doing something like this, if you're involved in making decisions about, hey, do we allow people to do remote access out to some other service? And you go, gosh, I wonder if that's okay. If you find that you struggle with that, welcome to the club because there really are no good guidelines or guidance for how you do it. It's a symptom of the immaturity, in some sense, of enterprise cybersecurity, and we'll get more into that later. But for now I want you to just understand policy lays out requirements, packet filter, firewall will do the implementation, sometimes they match, sometimes they don't. You want them to match but the policy rules in many cases are based on ad hoc representations of your business interest and your business need. I'll see you in the next video.
