10.1 Defining a Security Policy

10.1 Defining a Security Policy

Quick Answer: A security policy is a written document that defines the rules, responsibilities, and controls an organization uses to protect its information assets. It is built around the CIA triad (Confidentiality, Integrity, Availability), is driven by risk analysis, and for each risk you must consciously choose one of four responses: mitigate, accept, transfer, or avoid. Kali Linux operates under an assumed hostile-use context, so its own default policy is to run no listening network services at all.

What a Security Policy Is

A security policy is not a firewall rule or a password setting — it is the document that justifies those technical controls. It spells out, in plain language, what you are protecting, who is responsible for protecting it, what users are and are not allowed to do, and what happens when something goes wrong. The Kali Linux Revealed book stresses that the policy comes first: technical measures such as firewalls, encryption, and intrusion detection are only the implementation of decisions the policy already made.

A workable policy typically contains at least these elements:

• Scope: which systems, data, and people the policy covers
• Asset inventory and classification: what you own and how sensitive each asset is
• Roles and responsibilities: who administers systems, who approves changes, who responds to incidents
• Acceptable use rules: what employees may install, run, or connect
• Incident response procedures: whom to call and what to preserve when a breach is suspected

A policy that sits in a drawer and is never enforced is worse than useless, because it creates a false sense of security while documented rules are violated daily. Realism matters more than rigor: write rules people can actually follow.

The CIA Triad

Nearly every security goal can be expressed as protecting one of three properties, collectively called the CIA triad:

Some extended models add authenticity (you can verify who sent or created something) and non-repudiation (an actor cannot deny having performed an action). On the exam, when a scenario describes encrypted backups, signed packages, or redundant servers, map each control back to the CIA property it defends: encryption defends confidentiality, package signatures defend integrity and authenticity, and redundant systems defend availability.

Risk: Accept, Mitigate, Transfer, Avoid

A policy is shaped by risk analysis. Kali Linux Revealed frames this as three questions you must answer before choosing any tool: what are you trying to protect? (computers, or data — and which data), what are you trying to protect against? (leakage, accidental loss, revenue loss from downtime), and who are you trying to protect against? (a user's typo versus a determined attacker group). In the book's vocabulary, "risk" is the collection of those three answers. Two further points are easy exam targets: Bruce Schneier's motto that "security is a process, not a product" — assets, threats and attacker capability all evolve, so the policy must be revisited — and the reminder that cost is not only monetary, since user inconvenience and performance degradation constrain which policies are viable. The book also stresses that when it follows from a reasoned decision, no security policy is more or less respectable than any other, and that a small attack surface is easier to defend than a large one, so sensitive services belong on few machines behind few checkpoints. A threat is anything that can cause harm (a ransomware operator, a disgruntled employee, a flood). A vulnerability is a weakness the threat can exploit (an unpatched service, a weak password, a ground-floor server room). Risk is a function of how likely the threat is to strike and how large the impact would be. Once you have identified a risk, there are exactly four ways to treat it:

1. Mitigation — reduce the likelihood or impact with a control. Example: enable fail2ban so brute-force SSH attempts get banned after a few failures.
2. Acceptance — consciously decide the risk is too small or too expensive to fix. Example: accept the risk that a $200 spare printer is stolen rather than paying a $500 yearly insurance premium.
3. Transfer — shift the financial impact to a third party, typically through insurance or an outsourced service contract.
4. Avoidance — eliminate the activity that creates the risk. Example: do not run a public web server at all, so web-server vulnerabilities cannot hurt you.

The exam loves the distinction between acceptance and mitigation: acceptance means you documented the risk and chose to live with it, not that you forgot about it. Avoidance is often the cheapest option — Kali's default of running no network services is avoidance applied to an entire class of remote-attack risk.

Realistic Policies: Pentest Laptop vs Production Server

Policies fail when they ignore context. Consider two machines running the same Kali packages:

Both policies are "correct" because each is proportionate to the asset and its threats. Encrypting the pentest laptop is cheap and protects client confidentiality; demanding the same interactive LUKS passphrase on a headless production server may actually hurt availability, so the policy might instead place the server in a locked, monitored room.

Kali's Assumed Hostile-Use Context

Kali is unusual among Linux distributions because its intended use is adversarial. On any given engagement you will:

• run proof-of-concept exploit code downloaded from the internet, often with minimal review
• start and stop network services (an SMB share with impacket-smbserver, a temporary Apache server hosting a payload, a reverse-shell listener) on demand
• connect to hostile networks where every other device may be attacking you

Because of this, Kali's default security policy is deliberately conservative: network services such as SSH, Apache, and PostgreSQL are installed but disabled by default, so a freshly installed Kali machine exposes no network-reachable listening ports (loopback-only sockets such as systemd-resolved's 127.0.0.53:53 still exist). Nothing starts until you explicitly start it with systemctl start <service>. If you want a service to survive reboots you must also systemctl enable <service> — and doing so is a policy decision you should make consciously, because a permanently-enabled service on a laptop that roams hostile networks is a permanent attack surface.

A related policy consequence: Kali is a specialist tool, not a daily-driver desktop for banking and personal email. The book advises treating the Kali machine itself as potentially compromised — do not store your personal password vault or tax records on the same box where you execute random exploit code as root.

Common Exam Traps

• Confusing threat (the actor or event) with vulnerability (the weakness it exploits).
• Thinking encryption alone solves everything — it protects confidentiality and, with signatures, integrity, but does nothing for availability.
• Believing Kali's services are uninstalled by default. They are installed but disabled; that is a different, frequently tested statement.
• Assuming a policy is a technical artifact. It is a written, human document; technical controls merely implement it.