Sunday, August 30, 2009

Developing A Security Policy

expr:id='"post-" + data:post.id' >

Create a simple, generic policy for your system that your users can readily understand and follow. It should
protect the data you're safeguarding as well as the privacy of the users. Some things to consider adding are:
Linux Security HOWTO
2.4. Developing A Security Policy 4



who has access to the system (Can my friend use my account?), who's allowed to install software on the
system, who owns what data, disaster recovery, and appropriate use of the system.
A generally−accepted security policy starts with the phrase
" That which is not permitted is prohibited"
This means that unless you grant access to a service for a user, that user shouldn't be using that service until
you do grant access. Make sure the policies work on your regular user account. Saying, "Ah, I can't figure out
this permissions problem, I'll just do it as root" can lead to security holes that are very obvious, and even ones
that haven't been exploited yet.
rfc1244 is a document that describes how to create your own network security policy.
rfc1281 is a document that shows an example security policy with detailed descriptions of each step.
Finally, you might want to look at the COAST policy archive at ftp://coast.cs.purdue.edu/pub/doc/policy to
see what some real−life security policies look like.
2.5. Means of Securing Your Site
This document will discuss various means with which you can secure the assets you have worked hard for:
your local machine, your data, your users, your network, even your reputation. What would happen to your
reputation if an intruder deleted some of your users' data? Or defaced your web site? Or published your
company's corporate project plan for next quarter? If you are planning a network installation, there are many
factors you must take into account before adding a single machine to your network.
Even if you have a single dial up PPP account, or just a small site, this does not mean intruders won't be
interested in your systems. Large, high−profile sites are not the only targets −− many intruders simply want
to exploit as many sites as possible, regardless of their size. Additionally, they may use a security hole in
your site to gain access to other sites you're connected to.
Intruders have a lot of time on their hands, and can avoid guessing how you've obscured your system just by
trying all the possibilities. There are also a number of reasons an intruder may be interested in your systems,
which we will discuss later.
2.5.1. Host Security
Perhaps the area of security on which administrators concentrate most is host−based security. This typically
involves making sure your own system is secure, and hoping everyone else on your network does the same.
Choosing good passwords, securing your host's local network services, keeping good accounting records, and
upgrading programs with known security exploits are among the things the local security administrator is
responsible for doing. Although this is absolutely necessary, it can become a daunting task once your network
becomes larger than a few machines.
2.5.2. Local Network Security
Network security is as necessary as local host security. With hundreds, thousands, or more computers on the
same network, you can't rely on each one of those systems being secure. Ensuring that only authorized users
can use your network, building firewalls, using strong encryption, and ensuring there are no "rogue" (that is,
unsecured) machines on your network are all part of the network security administrator's duties.
This document will discuss some of the techniques used to secure your site, and hopefully show you some of
the ways to prevent an intruder from gaining access to what you are trying to protect.
2.5.3. Security Through Obscurity
One type of security that must be discussed is "security through obscurity". This means, for example, moving
a service that has known security vulnerabilities to a non−standard port in hopes that attackers won't notice
it's there and thus won't exploit it. Rest assured that they can determine that it's there and will exploit it.
Security through obscurity is no security at all. Simply because you may have a small site, or a relatively low
profile, does not mean an intruder won't be interested in what you have. We'll discuss what you're protecting
in the next sections.
2.6. Organization of This Document
This document has been divided into a number of sections. They cover several broad security issues. The
first, Section 3, covers how you need to protect your physical machine from tampering. The second, Section
4, describes how to protect your system from tampering by local users. The third, Section 5, shows you how
to setup your file systems and permissions on your files. The next, Section 6, discusses how to use encryption
to better secure your machine and network. Section 7 discusses what kernel options you should set or be
aware of for a more secure system. Section 8, describes how to better secure your Linux system from network
attacks. Section 9, discusses how to prepare your machine(s) before bringing them on−line. Next, Section 10,
discusses what to do when you detect a system compromise in progress or detect one that has recently
happened. In Section 11, some primary security resources are enumerated. The Q and A section Section 13,
answers some frequently−asked questions, and finally a conclusion in Section 14
The two main points to realize when reading this document are:
Be aware of your system. Check system logs such as /var/log/messages and keep an eye on
your system, and
·
Keep your system up−to−date by making sure you have installed the current versions of software and
have upgraded per security alerts. Just doing this will help make your system markedly more secure.

No comments: