7.1. Defining a Security Policy
It is impractical to discuss security in broad strokes since the idea represents a vast range of con-
cepts, tools, and procedures, none of which apply universally. Choosing among them requires a
precise idea of what your goals are. Securing a system starts with answering a few questions. Rush-
ing headlong into implementing an arbitrary set of tools runs the risk of focusing on the wrong
aspects of security.
It is usually best to determine a specific goal. A good approach to help with that determination
starts with the following questions:
• What are you trying to protect? The security policy will be different depending on whether
you want to protect computers or data. In the latter case, you also need to know which data.
• What are you trying to protect against? Is it leakage of confidential data? Accidental data
loss? Revenue loss caused by disruption of service?
• Also, who are you trying to protect against? Security measures will be quite different for
guarding against a typo by a regular user of the system versus protecting against a deter-
mined external attacker group.
The term ”risk” is customarily used to refer collectively to these three factors: what to protect,
what should be prevented, and who might make this happen. Modeling the risk requires answers
to these three questions. From this risk model, a security policy can be constructed and the policy
can be implemented with concrete actions.
Permanent Questioning
Bruce Schneier, a world expert in security matters (not only computer security), tries
to counter one of security’s most important myths with a motto: “Security is a process,
not a product.” Assets to be protected change over time and so do threats and the
means available to potential attackers. Even if a security policy has initially been
perfectly designed and implemented, you should never rest on your laurels. The risk
components evolve and the response to that risk must evolve accordingly.
Extra constraints are also worth taking into account as they can restrict the range of available
policies. How far are you willing to go to secure a system? This question has a major impact on
which policy to implement. Too often, the answer is only defined in terms of monetary costs,
156
Kali Linux Revealed
but other elements should also be considered, such as the amount of inconvenience imposed on
system users or performance degradation.
Once the risk has been modeled, you can start thinking about designing an actual security policy.
There are extremes that can come into play when deciding the level of security protections to
adopt. On one hand, it can be extremely simple to provide basic system security.
For instance, if the system to be protected only comprises a second-hand computer, the sole use of
which is to add a few numbers at the end of the day, deciding not to do anything special to protect
it would be quite reasonable. The intrinsic value of the system is low and the value of the data
are zero since they are not stored on the computer. A potential attacker infiltrating this system
would only gain a calculator. The cost of securing such a system would probably be greater than
the cost of a breach.
At the other end of the spectrum, you might want to protect the confidentiality of secret data in
the most comprehensive way possible, trumping any other consideration. In this case, an appro-
priate response would be the total destruction of the data (securely erasing the files, shredding of
the hard disks to bits, then dissolving these bits in acid, and so on). If there is an additional require-
ment that data must be kept in store for future use (although not necessarily readily available),
and if cost still isn’t a factor, then a starting point would be storing the data on iridium–platinum
alloy plates stored in bomb-proof bunkers under various mountains in the world, each of which
being (of course) both entirely secret and guarded by entire armies.
Extreme though these examples may seem, they would nevertheless be an adequate response to
certain defined risks, insofar as they are the outcome of a thought process that takes into account
the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security
policy is more, or less, respectable than any other.
Coming back to a more typical case, an information system can be segmented into consistent and
mostly independent subsystems. Each subsystem will have its own requirements and constraints,
and so the risk assessment and the design of the security policy should be undertaken separately
for each. A good principle to keep in mind is that a small attack surface is easier to defend than a
large one. The network organization should also be designed accordingly: the sensitive services
should be concentrated on a small number of machines, and these machines should only be ac-
cessible via a minimal number of routes or check-points. The logic is straightforward: it is easier
to secure these checkpoints than to secure all the sensitive machines against the entirety of the
outside world. It is at this point that the usefulness of network filtering (including by firewalls)
becomes apparent. This filtering can be implemented with dedicated hardware but a simpler and
more flexible solution is to use a software firewall such as the one integrated in the Linux kernel.
157
Chapter 7 — Securing and Monitoring Kali Linux
|
