🧙♂️ How to choose a standard?
The Fellowship - Week 9
Welcome to the ninth edition of The Fellowship Newsletter.
Last week I wrote about finding inspiration for new content ideas. It was the first newsletter I narrated, and the first time I answered a reader's question. This week I respond to a question asked by Rowan Troy.
How do you know what standards to choose when writing policy?
This is a superb question. It allows me to delve into the world of security policy drivers—the reasons for implementing security policies. Before I dig into the drivers, let’s focus on the primary and secondary security objectives. This is what we are trying to achieve.
The primary objective of the security function
To advise the organisation on safeguarding operating conditions to prevent behaviour impacting its ability to create protected value.
The secondary objective of the security function
To identify and respond to occurrences of unwanted behaviour that were able to avoid the safeguards and implement countermeasures to reduce the impact of possible harm.
Neither aliens nor robots are attacking us, not for now, at least. Security is a problem of the behaviour of people. It’s not solely a problem of people external to the organisation. It can be internal people too. Generally, people want to be good. They want to go to work, do a good job, get paid, and go home. They don’t want to do something that might jeopardise that.
However, work is complicated. There are lots of things to think about. Pressures are put on our staff that can make them do things accidentally that cause harm to the organisation. Internal people cause between 70 & 90% of all data loss. We have several drivers (reasons) to stop this from happening.
What are the main drivers for security policies and procedures?
1. Legal or regulatory obligation
Organisations are not permitted to do anything they like without consequences. Like all of us as individual citizens, they are required to follow all laws that apply to them. Those laws can apply to organisations in specific industries or regions. They can be based on their work or the organisation's size (either by the number of employees, customers, or the size of the organisation's revenue).
In 2018 the EU implemented the General Data Protection Regulation (GDPR). For the first time, the people of Europe have rights over how their personal data is used. The eight rights are:
The right to be informed
The right to access
The right to rectification
The right to erasure
The right to restrict processing
The right to data portability
The right to object
Rights concerning automated decision-making and profiling
GDPR obligated countries within the EU to enact a law specific to their jurisdiction that enforces the regulation. In the UK, that law is the Data Protection Act (2018), revised in 2022.
In addition to the rights of the data subject (individual citizens), Chapter 2 of the act requires that Data Controllers (organisations collecting data) handle that data by following seven fundamental principles:
Lawfulness, fairness and transparency
Purpose limitation
Data minimisation
Accuracy
Storage limitation
Integrity and confidentiality (security)
Accountability
“The sixth data protection principle is that personal data processed for any of the lawful purposes must be so processed in a manner that ensures appropriate security of the personal data, using appropriate technical or organisational measures (and, in this principle, “appropriate security” includes protection against unauthorised or unlawful processing and against accidental loss, destruction or damage).”
Heavy fines for non-compliance with the law have encouraged (forced) organisations to take data security seriously. Governing bodies (the Information Commissioner’s Office in the UK) hold organisations accountable to the laws. As such, every organisation needs to implement controls to reduce the risk of a data breach. Showing due diligence and taking steps to prevent data breaches can lessen the impact of any fines issued for those breaches.
To do this, many organisations implement Information Security Management Systems (ISMS) to reduce the risk of a breach. Having an ISMS shows due diligence. One method of implementing an ISMS is to use an industry standard such as ISO 27001 or the National Institute of Science and Technology (NIST) Cybersecurity Framework. Many security frameworks require organisations to implement security policies before being assessed as compliant.
Other laws in other areas of the world are also helping to enhance the protection of citizens' personal information. In the USA, the Health Information Portability and Accountability Act (HIPAA), the California Consumer Privacy Act (CCPA), and the California Privacy Rights Act (CPRA) implement requirements for organisations to protect personal data from unauthorised disclosure. Slowly but surely, other countries are enforcing laws to protect their citizens.
2. Customer requirement
A big driver for organisations to implement security policies and procedures is to satisfy the due diligence of customers. Any organisation that is required to secure personal data because of their responsibilities under the laws in paragraph 1 will also require that other businesses in their supply chain are also taking steps to prevent data breaches. Most security frameworks list Third-party Risk Management as a requirement.
Often these requirements are set by governments. In the UK, the government requires all organisations tendering for government contracts to have a Cyber Essentials (Plus) certification before being considered.
The method used by most organisations for the Third-party Risk Management process often requires the completion of security questionnaires. These are typically an excel worksheet that has a couple of hundred questions. For each question, the service supplier is required to provide an answer. The customer often requests evidence to support the provided responses.
That evidence can include screenshots of configurations, copies of certifications (e.g., ISO 27001), attestations (e.g., SOC 2 Type 2), external audit reports, and copies of security policies and procedures.
3. Consistency of Operational Security Configurations
The consistency of security messaging and configuration information is at the heart of the reasoning for security policies. They are the definitive source of truth. When staff are configuring systems, we want them to do that securely and to the requirements set by security management.
When security policies, procedures, and standards give clear, fact-based instructions, the staff have a consistent set of instructions that they can use to guide their decision-making and work product.
According to SOCRadar, misconfiguration has caused 35% of all Cyber Incidents. Providing staff with clear instructions and rules will inevitably reduce the instances of misconfigured systems.
Take launching a new virtual server as an example. An organisation might launch multiple thousands of new instances each month. Creating a virtual server, configured (hardened) to reduce vulnerabilities that all staff can use as an image to launch new servers will significantly reduce the effort required by the vulnerability management team.
This simple change will reduce the time to launch a machine, the number of devices with vulnerabilities, and the number of vulnerabilities and accidental misconfigurations. The cost savings are exponential as well. The operational requirements can be enforced through an administrative disciplinary procedure for staff who violate security policies and procedures.
4. Continuity of value generation
Our objective as a security function is to prevent behaviour that might affect our ability to complete our primary and secondary objectives. That’s the meat and veg of security. [1]Our job is to reduce the opportunity for people (internal or external) to destroy our opportunity to create value, denying us the opportunity to use our tools, devaluing our products or services, and degrading the value we have created.
To do that effectively, we need to understand what behaviour we are trying to prevent and where to stop it from happening. We need to understand the operating conditions.
What do we have in our environment?
What do the things do for our business?
What is the nature of the system or process?
What is the value that the system or process creates?
If Ransomware hit it for 24 hours, what would we lose?
Then we need to create risk scenarios that help us to recognise where our security defences are fragile and where we need to implement safeguards and countermeasures. We are not interested in environmental events like tornados and earthquakes; those are not in our remit as security practitioners. We need to focus on the interaction of people with information systems.
I have created a generic database of 98 human behaviours that could potentially cause harm to business operations. It is not specific to any business. It allows me to assess if the behaviour is internal or external, malicious or accidental, which assets it could harm, and the security exposures (general vulnerabilities) that could be exploited.
Security exists on a sliding scale. The more functionality an environment has, the less secure it is. Conversely, the more secure an environment, the less functionality it has. This is where we need to ensure that the safeguards and countermeasures we implement do not reduce the environment's functionality to a level that impacts the organisation's ability to create value. It needs to be delicately controlled by security management.
Using the risk scenarios, we can conduct a gap analysis on the security policy framework to check which risks are not covered by a safeguard. If we identify any gaps, policy statements that address the areas of concern can be drafted and implemented within existing policies, or where required, a new policy can be added.
Security policies are the root of all control.
Security policies are the root of all control. It’s how we implement and communicate the security requirements to everyone in the business and ensure that the required functionality is not impacted by the rules we implement. Our security policies address our security risks and help us to implement our security controls. Our security controls allow us to mitigate security risks. It’s a feedback loop. Changing the risks will require changing the policies and controls.
In conclusion
Rowan asked:
How do you know what standards to choose when writing policy?
Answer:
Security policies are created for several reasons. If you build for compliance (choosing a standard), you will leave potential areas of concern undiscovered. If we build for security, we get compliance for free. You should focus your security policies on the behaviours you try to prevent. Don’t write policies because a security framework requires it or an auditor says it’s needed. Address the security concerns applicable to the organisation, don’t implement a generic set of policies to meet compliance.
Learn with me
If you’re ready, there are three ways that I can help you:
Take the security policy foundations course.
Book a 60-minute 1:1 coaching session.
Upgrade to a premium subscription.
That’s it for this week. I hope you’ve enjoyed learning about the drivers for security policies and procedures. Let me know what you think in the comments or on LinkedIn. If you liked it, consider sharing it with your peers.
Client testimonials
Until the next adventure!
Stuart Wedge 🧙♂️
PolicyWizard
[1] Dr Richard Diston – Why the CIA Triad must die