2 - Raspberry PI Community Projects

14.1. Defining a Security Policy
CAUTION
Scope of this chapter
Security is a vast and very sensitive subject, so we cannot claim to describe
it in any kind of comprehensive manner in the course of a single chapter.
We will only delineate a few important points and describe some of the tools
and methods that can be of use in the security domain. For further reading,
literature abounds, and entire books have been devoted to the subject. An
excellent starting point would be Linux Server Security by Michael D. Bauer
(published by O'Reilly).
The word “security” itself covers a vast range of concepts, 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. Rushing headlong into implementing an
arbitrary set of tools runs the risk of focusing on the wrong aspects of security.
The very first thing to determine is therefore the goal. A good approach to help with that determination
starts with the following questions:
• What are we trying to protect? The security policy will be different depending on whether
we want to protect computers or data. In the latter case, we also need to know which data.
• What are we trying to protect against? Is it leakage of confidential data? Accidental data
loss? Revenue loss caused by disruption of service?
• Also, who are we trying to protect against? Security measures will be quite different for
guarding against a typo by a regular user of the system than they would be when protecting
against a determined attacker group.
The term “risk” is customarily used to refer collectively to these three factors: what to protect,
what needs to be prevented from happening, and who will try to make it 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.
NOTE
Permanent questioning
Bruce Schneier, a world expert in security maers (not only computer security)
tries to counter one of security's most important myths with a moo:
“Security is a process, not a product”. Assets to be protected change in time,
and so do threats and the means available to potential aackers. Even if a
security policy has initially been perfectly designed and implemented, one
should never rest on one's 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 we are willing to go to secure a system? This question has a major impact
on the policy to implement. The answer is too often only defined in terms of monetary costs,
374 The Debian Administrator's Handbook