CISO starter pack - Security Policy

A wise man once said a computer network is 100% secure…​until you add the human element. It’s easy to lock everything down, but business continuity would suffer if employees couldn’t perform basic tasks. Conversely, running without an IT Security Policy is effortless, but business continuity would suffer in the first critical incident. Therefore, the best policies land you right in the middle, like it’s the best bowl of porridge you’ve ever had. A clear understanding of the business requirements is critical to developing processes that can control and secure them. Interviews with as many people as possible will give you the greatest clarity on the exact business requirements. More than one person or department may have special needs or knowledge about these.

Once you know what the business requires, you can implement processes by following the principle of least privilege (PLP). PLP is where you only grant as much permission as needed to get job requirements accomplished. If Joe Schmo needed access to Sales but not accounting, you wouldn’t hand him an accounting key. The same theory applies to PLP but with computer files and folders. You’d make it so that Joe can access the Sales files, not Susan’s payroll. Developing these processes is much easier once you know the requirements of the business.

As you build out these controls, you’ll make decisions on a larger scale, potentially impacting a significant subset of employees. Examples include allowing or blocking certain websites on business networks, which affects everyone in the company. Whenever you need to make a decision that impacts a large user base, it’s essential to categorize or generalize as much as possible. For example, do it by category if you need to filter internet requests. By implementing business processes generally and with PLP, you’ll improve at balancing business needs with security requirements. However, if no one understands or interprets the IT security policy, this will be for nothing.

If you know anyone in IT, you know sometimes they can accidentally begin speaking…​technical. We can’t help; it starts with talking about USBs and ends with a theoretical approach to network management. You can see the glaze rolls over their eyes like a wave when it becomes technical. A similar reaction occurs when a security policy begins tossing around jargon and technical terms. Ensuring your security policy is free of technical terms, or includes a glossary, is critical. Once employees can translate what they’re reading to their daily tasks, security adoption becomes easier. First, they must read it, and administrators must ensure this happens.

A security policy is no good if no one reads it. When disaster strikes, vulnerability scans, acceptable use, incident response, and disaster recovery are not policies you want to read. Ensuring employees and staff clearly understand this policy is just as important as the effort to make it. Buy-in from department heads and managers sets a strong tone for others to follow. Stakeholders mentioned within it should note that they may have special tasks they need to perform. This goes with not using jargon in your policy and translating the security requirements in layman’s terms. No one will read it if no one can understand it, which will directly impact your overall security posture. How, then, does one communicate and translate the policy elements in a way everyone understands? Games.

Ok, we’re not talking about zoned districts but tabletop exercises for your employees. When discussing tabletop exercises for your organization, we’re referring to your incident response plan. As riveting as it may be to walk through your acceptable use policy, it may not have the desired effect. Tabletop exercises are scenarios written to walk employees through your incident response plan. Therefore, these exercises reflect the existing policies in your security policy as they are in your environment. Think of it like a dungeon and dragons game; instead of paladins and fire blasts, you have hackers and phishing attacks. Administrators explain the situation, and the employees react based on their knowledge. They can ask questions, and the administrator will respond to progress the exercise. Afterward, it’s essential to review what happened and make any changes to the policy if needed. You may need to change roles or positions, or you may need to change how you respond to a specific situation. These exercises aim to flesh out these sorts of changes before danger hits. Once finished, the reading and education process must loop again to ensure everyone is aware of the changes. 

Policies are translated business requirements placing constraints on the environment. Log collection is part of a set of critical underlying processes helping secure the three core tenants of cybersecurity: confidentiality, availability, and integrity. When investigators begin looking into incidents, they’re looking for non-repudiated data or data containing proof of origin. Non-repudiated data has integrity, as you cannot dispute the source. As long as the data is stored securely and available to all investigators, it checks the 'cybersecurity' proverbial checkbox. Log data helps ensure these characteristics exist; it’s up to the CISO to use this data effectively.