Let's take a look at module 3 then, best-practice security policies. This is a reminder of our administrative controls and the different types that we have. We should broaden out some of the types that we haven't looked at yet. Data Handling Policy, Password Policy, an Acceptable Use Policy, Bring Your Own Device Policy, Change Management Policy, a Privacy Policy, and some Privacy Terminology for us. As we've said, these are an opportunity for us to say what we do very clearly so people know what it is we're doing. If we have these policies, these procedures, we need to train people in them. But now, this provides guidance for the entire organization. Then when we are checking compliance or we're being audited, people can then check that we're doing what we say we do. Really simple conceptual. Explicit statements over policy provide clarity. Policies are a high-level statements. These are the what we're doing and the why we're doing it. The procedures align to policies, these are the implementations of our policies. These are step-by-step instructions on how to do something. Policies are the what and the why, and the procedures, or sometimes called processes, are the how we do them. Policies are signed off at the top by those C-level offices. Procedures are usually signed off at a team level or within business units. The step-by-step instructions at how we do things in those procedures, they need that low-level of knowledge. Policies and procedures then guide people's behaviors. We augment them, as we said back in Chapter 1, through the use of physical and logical controls as well. What happens when there are gaps? Really good question. If you don't tell people what to do, can you challenge them when they don't do it? Really good example here is a high-school I audited. One of the teachers was fired for using Internet for personal usage, for doing online banking. The teacher said, "Well, look, everybody does this. I thought it was okay." Investigating, roughly half the staff thought that it was okay, half the staff thought that it wasn't okay. Depending on who you worked with. There were groups of people thought it was fine. Groups that thought it was unacceptable. Unless you tell people what is acceptable, what is unacceptable, it is very hard to hold them to account. In that instance, the teacher that was fired was unfired. They were reinstated in their position. Why? Well, because roughly half of the staff were doing exactly the same thing and there was no clear guidance on whether it was acceptable or not. Making sure that we are clear in terms of what is permissible and what is not permissible is important. Again, often, this will support regulatory requirements. We may have to do this. If we work in a bank, if we work for a telecommunications provider, typically, our policies and procedures will be shaped not just by the C-level officers, but by the requirements legally that we have to abide by. Data handling policies then. We see data handling policies. These help us with our classification levels. How should we handle data at rest, in motion, in process? What about the physical and logical operational environments? What do we do with printed documents? How do we dispose a data? What about encryption standards? When should they be applied? Key size and so on. A password policy. Dictating the types of password protections we need for different accounts. Bearing in mind that different accounts may need different levels of protection. For some accounts, we may have single factor authentication. For some, multifactor authentication, the password history, the password length, the password complexity, and so on. Actually, the different options we see there are all about getting a level of assurance for our authentication. We're adapting based on risk, remember. Common seen lots of organizations now allowing people to bring their own devices, third-party hardware and software. How do we get a level of assurance that these devices are not going to cause problems for our network, for our organization's network, and also that they're going to maintain a security posture for the information contained within them? If you allow people to connect and download that email to a personal device, is that email going to be as well-protected as it would be on a corporate device? We think about things like operating systems, actual devices themselves, and shadow technologies, things like tablets that maybe aren't designed for enterprises. If you think about something like a tablet, many tablets are created as single-user devices. Whoever logs in gets everything that anybody else who logs in gets. Most laptops support different user accounts. It's a fundamental difference in approach to security. Some of these home user devices were not designed as enterprise devices. We see BYOC there, Bring Your Own Cloud. The idea that you can bring some of your own Cloud services, very often, things like Cloud storage, Cloud email, to the organization. What does that mean in terms of compliance? Commonly, that Bring Your Own Cloud is a massive issue in terms of compliance. Where is it storing data? Do you, as an organization, have access to your data anymore if it goes into somebody else's Cloud? Often not, you lack visibility. It's a form of exfiltration. Your employee could have taken your data and unknowingly or unconsciously exfiltrated it to their cloud system, which may be held at a lower security level in a jurisdiction that is non-compliant, maybe. What do we do with Bring Your Own Device? Commonly, we use mobile device management software. This software checks that the device meets minimum security requirements, meets your baselines, and it differentiates personal devices from corporate devices. That way when it comes time to wipe the device or if somebody leaves, recover the device, any personal devices are marked as personal. We try to keep our data separate from the personal data. We create a sandbox. Any corporate data goes into this corporate sandbox. If the employee leaves or loses the device, you can delete that portion of the device. It's not possible and certainly not advisable to wipe a user's personal device. But you can wipe your element, your data, your corporate data from that personal device. That's what sandboxing allows us to do. Whole range of considerations. It is far more complex than that, practically. Getting the right policies procedures right for something like Bring Your Own Device, absolutely critical to avoid compliance issues and inadvertent loss of data for both the individual and also for the organization.
