By Kurt Seifried [email protected]
Security is risk management. - unknown
"A computer is secure if you can depend on it and it's software to behave as you expect" - Practical UNIX and Internet Security
Security is: availability, consistency, access control, data confidentiality, authentication. - http://www.sun.com/security/overview.html
"The principal objective of computer security is to protect and assure the confidentiality, integrity, and availability of automated information systems and the data they contain." - http://csrc.nist.gov/publications/secpubs/cslaw.txt
There are numerous definitions for "computer security", and most of them are correct. Essentially computer security means enforcement of usage policies, this must be done since people and software have flaws that can result in accidents, but also because someone may want to steal your information, use your resources inappropriately or simply deny you the use of your resources.
A security policy is an expression of your organizations security goals. Security goals will vary greatly by organization, for example a software vendor is typically more concerned about the confidentiality and integrity of their source code anything else, while a pornographic website is probably more concerned about processing credit cards online. There is an immense amount of security technology available, from software and hardware to specific techniques and implementations. You cannot properly implement the technology without a solid idea of what your goals are. Do home users connecting to the office need to use VPN software? If your security policy states that all file and print transfers must either be encrypted or sent across a "trusted" network then the answer is probably yes. What authentication methods are acceptable for services that can be reached from the Internet? Do you require strong passwords, tokens, biometric authentication, or some combination? The data you collect from remote sites, is it more important that this data is collected, or is it more important that this data remain secret? Data that is remote weather telemetry is probably not as sensitive as credit card numbers.
Some security policies will need to be exceptionally broad and general, for example the security policy for JANET, the academic backbone network for England states:
Monitoring and Enforcement
19. It follows from the policy of cascaded responsibility backed up by written site agreements, that there must be some method for UKERNA to enforce the possible disconnection envisaged by the AUP, and to provide full access and assistance to law enforcement agencies where necessary.
20. The JANET-CERT has therefore been given the responsibility (in conjunction with UKERNA) to
- Monitor use of the network, as far as is possible while respecting privacy, either in response to information about a specific threat, or generally because of a perceived situation
- Require a primary site, through its nominated contact, to rectify any omission in its duty of responsibility
- Where a site is unable or unwilling to co-operate, report the issue to UKERNA and initiate the procedure for achieving an emergency disconnection
- Obtain evidence and pass on information as necessary in order to assist an investigation by a law enforcement agency
- Provide support and co-ordination for investigations into breaches of security
On the other hand a security policiy can be fine grained:
All internal email must be encrypted with PGP or GnuPG using a key of at least 1024 bits that is signed by an authorized signing entity.
Generally speaking the more detailed and technology oriented a security policy is the harder it will be to follow and keep up to date. The actuall technical details of implementing a security policy should be seperated from it. Keeping a seperate set of best practices or an actually "implementation of security policy" document is a better idea then rolling it all into the security policy.
Another component of computer security is an AUP (Acceptable Use Policy). This is a document that sates what a user of your resources may or may not do with them. Typically it is part of a contract and is signed at the time when the services are purchased. Many acceptable use policies generally forbid actions that are illegal, potentially annoying to other people (and hence likely to cause problems for the provider inthe form of complaints) or are controversial (such as pornography). Other standard clauses include "this notice may change at any time without warning" and "we can terminate your service (or fire you) at any time without warning if you violate this policy. Generally speaking the majority of AUP's are reasonable and will not be a problem for normal users. These are a good compliment to a security policy as they set out in concret terms what a user is or is not allowed to do, and as they are often part of a contract it allows a provider to enforce their security policy when a user attempts to violate it or has violated it.
Privacy policies are interesting in that they are supposed to prevent an organization 9typically a company) from violating some aspects of a user's security (specifically the confidentiality of their information). Unfortunately the majority of privacy policies contain clauses like "this policy may change at any time without warning" or are simply discarded when a company decides to profit off of a user's information (such as name, address, credit card details, purchase history, etc.).
You only need to make one mistake or leave one flaw available for an attacker to get in. This of course means that most sites will eventually be broken into. Witness the effects of Code Red, an Nimda, both of which were hugely succesful exploiting well known and long solved vulnerabilities in the Microsoft IIS server. Regularily apply patches (after testing them). Regularly scan your network for open ports. Regularly scan your servers with intrusion testing software such as Nessus. Audit file permissions and make sure there are no unexpected setuid or setgid binaries.
All technical security measures will eventually fail or be vulnerable to an attacker. This is why you must have multiple layers of protection. Firewalls are not enough, you may accidently forget a rule or leave yourself exposed while reinitializing a ruleset, use tcp_wrappers to restrict access to services as well where possible. Restrict which users can access these services, especially if only a few users need access. Encrypt traffic where possible so that attackers cannot easily snoop usernames and passwords or hijack sessions. Since security measures will fail you also need a strong audit and logging process so that you can later find out what went wrong and how bad it is.
These are just a handful of thousands of specific technical problems facing security administrators.
One of the biggest security challenges is the increase in network connectivity. If you have a machine that is not connected to any other machines an attacker will generally need to gain physical access. This of course greatly narrows down the number of attackers. However with everything connected to the Internet there are over 100 million people that can potentially get into your machine.
This is one of the problems that has caused no end of security problems since day one. Vendors typically ship their operating systems with insecure defaults (i.e. finger, telnet, ftp, etc.) meaning that administrators must expend a lot of effort to close security problems before they can even start to pro-actively secure their systems and networks.
Because you must grant legitimate users access to resources there is always the potential for attackers to gain access. Attacker can guess authentication credentials (i.e. weak passwords), steal them (password sniffing), exploit flaws in the server itself and so on.
When possible restrict access. If you do not need to run fingerd turn it off and remove it. An attacker cannot exploit fingerd if it isn't present. Keep users off of servers if possible, if they need shell accounts for some reason setup a separate system and partition it off from the rest of your network. Lock down workstations where possible, set BIOS passwords, secure the boot sequence, do not give them administrative access.
Last updated on 1/10/2001
Copyright Kurt Seifried 2001 [email protected]