[00:00] Security zones are groups of gateways, computers and I.P addresses that can have a security policy applied to them. This allows you to configure security restrictions to incoming connections based on the source of the connection. You can see, I have my designer open here. This was launched from a remote gateway. On my gateway, I've created a remote tag provider, and just looking at my looking at my local systems, site A tag A provider. If I tried to write to one of these writable tags. I get a little error message. This is because the security zone is restricting write access to these tags. So let's see if we can modify this. I'm going to close this error and I'm going to head over to my gateway. Now this is my local gateway, which houses the tag provider I just tried to write to remotely. You see, I have two security zones already created. Zone one and default. Default is always present and it can't be modified. You see there isn't a delete or edit button over here. The reason for this is because of a incoming connection does not cleanly fall into one of my other zones. We will place it in my default zone. But let's take a look at what I've done with zone one. So I'm going to click the edit button here. And I'm scroll down my list. And there are two main sections you're going to want to be aware of. The identifiers and the qualifiers. Identifiers are a list of checks about the locations of the incoming connection. When someone tries to connect to my local system here, we'll check each three of these properties to see if atleast one of these configured values matches the incoming connection. So in this case, I have the IP address and the gateway name defined. You can have multiple identifiers configured, but to be placed into this security zone, the incoming connection only has to match one of the identifiers. Each identifier takes comma separated values so you can specify multiple values for each property. Additionally, you can use the asterisk as a wildcard character. So if at least one of the identifiers match, we have the checked qualifiers. All of the qualifiers have to match for the connection to be placed within the security zone. So for example, in this security zone, if I only wanted direct connections, I didn't want to use a proxy gateway at all, I can toggle my direct connections required. So I am going to use the same settings. I am going to scroll back up. And under security, I am going to go to the service security page. So once you've created your security zone, the next step is to define a policy on each one. You can see both of the security zones here. You can see that I have policies defined on both of them. And you'll also notice that I can change the order at which they are listed here. The reason for this is, if an incoming connection potentially falls into multiple security zones, when you look at this list here, start at the top and work your way down. Whichever security zones the connections falls into first, is the one we use. So the order does matter here. Now, I know my zone one policy is what's preventing the tag, right. So let's edit this policy. And if I scroll down, you'll see a list of subsystems that I can figure my security policy for. Under each sub system, there's a service access property here which basically allows us to turn off the subsystem to any remote connections. This allows me to protect my subsystems from any remote connections placed into the security zone. Now I can deny access to my local alarm notification subsystem. Now scroll down here a little bit more. Let's take a look at history provider access and tag access. Both of these subsystems have a default access level of some sort. They also list each individual provider within their subsystem here. So by default, all of the providers will use the default access level. Which, in this case, from my tag providers, is read only. But I can also specify individual providers to have a different access level. So I know I want to write to my site from A provider here. So I am going to change this from inherited to readwrite. So my default and system tag providers will still inherit the only read only access level. Where as my site A will now use readwrite. So I'm going to scroll down here a little bit further. I'm going to click save. Let's switch back to the designer so we can test this out. With the changes to the security zone in place, I can try and write to the tag one more time. And this time, the write went through. So security zones, you have a great way to completely deny or allow access to some subsystem without opening the entire system up to another remote connection. I'll head back to the gateway for one more point. The default security zone does not have a policy to find automatically. This policy here was added at an earlier date. As stated earlier, connections that do not fall into another policy, will fall back to the default security zone. Because of this, it is recommended to add a policy to the default zone and make it as restrictive as allowable.