Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Softpanorama Laws of Computer Security

Dr. Nikolai Bezroukov

Version 0.41 (Early Draft)

Abstract

Computer security is  a very loaded term. One aspect of security is so called hardening, which is currently is one of the most fashionable topics. the latter is essentially an attempt to convert a general purpose server into an appliance to improve the level of protection from external as well as internal threats, including the "fifth column" problem; there is no free lunch and hardening generally makes server less Unix user/developers friendly.  Given that complexity is the biggest single enemy of security, it's only logical to remove everything that is not essential for the task in hand, users be damned ;-)

Although few, if any, fundamentally new Unix vulnerabilities are evident today, most today's Unixes do not include advanced security techniques, let alone the enhancements identified as essential to fight them. Solaris is one of the better Unixes in this respect and it does include some interesting features like advanced file attributes, roles and, especially, zones and privileges management (in Solaris 10+).

The author argues that deep hardening is essentially a process of conversion of general purpose Os into a specialized OS and  that's why for organizations without much local talent it might be better to use appliances.

There are also some inherent limitqtions in the level of security achivable in any given organization. The author formulated three laws of Computer Security:

Softpanorama First Law of Computer Security:

The level of security of any Unix environment can not be significantly different from the level of qualification of system administrator(s) responsible for this environment...

Softpanorama Second Law of Computer Security:

If a large discrepancy between the level of qualification of system administrator(s) and the level of Computer Security of the system exists, the main trend is toward restoring equilibrium at some, not so distant, point...

Softpanorama Third Law of Computer Security

In a large corporate environment incompetent people implementing security solutions are a bigger problem that most OS security weaknesses.  The real computer security skills presuppose not only the knowledge of what should be done, but the knowledge were to stop. The latter skills are completely lacking in wanna-be security specialists. If incompetents happen to be in charge of security one should expect that they will implement the most destructive for corporate IT measures  dictated by the current fashion, driven by excessive zeal and desire to survive.

This article is an attempt of skeptic treatment of this theme and is a modest attempt to fight "security fascism":  counterproductive restrictions that complicate user and system administrator lives, while adding nothing of even diminishing security. There is almost no articles on the WEB that are critical or even slightly skeptical about security tools in general and Computer Security security tools in particular.   This article tries to fill the gap.

Introduction

Security is like an erection: with proper drugs
it can always be harder and longer lasting but it never lasts forever.
Also that doesn't necessarily imply your initial impotence.
Slightly modified Slashdot post (#10252795)

Not too much zeal!
Charles-Maurice de Talleyrand
advice to new diplomats

Computer security currently is one of the most fashionable topics. Important part of computer security is related to hardening: making a system or network of computers less vulnerable to some broadly defined class of attacks.  It is essentially an attempt to convert a general purpose server into a less flexible (and less useful) appliance. There is no free lunch and in order to improve the level of protection from  external as well as internal threats, including the "fifth column" problem to make the server less user/developers friendly. 

Given that complexity is the biggest single enemy of security, it's only logical to remove everything that is not essential for the task in hand, users be damned ;-) Although few, if any, fundamentally new Unix vulnerabilities are evident today, most today's Unixes do not include advanced security techniques, let alone the enhancements identified as essential to fight them. Solaris is one of the better Unixes in this respect and it does include some interesting features like advanced file attributes, roles and, especially, zones and privileges management (in Solaris 10+)

This article is an attempt of skeptic treatment of this theme and is a modest attempt to fight "security fascism":  counterproductive restrictions that complicate user and system administrator lives, while adding nothing of even diminishing security. There is almost no articles on the WEB that are critical or even slightly skeptical about security tools in general and hardening security tools in particular.   This article tries to fill the gap.

It's important to understand that you should not take anything for granted, especially in security. If you are confused by the stream of software, hardware, and services hanging their claim to fame on better security, please be aware that security is probably the second most promising IT field for snake-oil salesmen after (or may be even before) software development methodologies ;-) We're all for better security, but often "security" is used like a universal door-opening key by yet another variety of  "ambulance chasing lawyers" to force on the customers useless or even harmful product that trivialize the really complex issues involved. "Mistrust first impulses" this advice of Talleyrand  is especially applicable to hardening.
 

Softpanorama laws of hardening

The author formulated the following laws of computer security:

Softpanorama First Law of Computer Security:

The level of security of any Unix environment can not be significantly different from the level of qualification of system administrator(s) responsible for this environment...

Softpanorama Second Law of Computer Security:

If a large discrepancy between the level of qualification of system administrator(s) and the level of Computer Security of the system exists, the main trend is toward restoring equilibrium at some, not so distant, point...

Softpanorama Third Law of Computer Security

In a large corporate environment incompetent people implementing security solutions are a bigger problem that most OS security weaknesses.  The real computer security skills presuppose not only the knowledge of what should be done, but the knowledge were to stop. The latter skills are completely lacking in wanna-be security specialists. If incompetents happen to be in charge of security one should expect that they will implement the most destructive for corporate IT measures  dictated by the current fashion, driven by excessive zeal and desire to survive.

The first law if commented to the fact that the security is always as strong as the weakest link and most often the weakest link is the security specialist in change of security and system administrators who are responsible for the particular server.  In case measures severely limited server functionality are implemented the natural tendency of users and administrators alone is to adopts set of behaviors which to certain extent try to restore the user friendliness of the system.  Often such behaviors are more dangerous then the real or fake threats that were stimulus for implementing the measures in the first place.

Oversimplifying we can state that the hardening involves two separate phases:

• Identification of how a server will actually be used (server role). Please note that actual role can be very different from the role that, say, DMZ architect initially envisioned for the server.
• Systematic removal and/or disabling all system components not necessary for that role/function. 

That means that hardening is by-and-large a role specific operation and that such set of scripts as Titan and JASS can be only the first step to deep hardening. The deeper the hardening level that one wants to achieve, the more role specific it should be and the less suitable for anything else outside this role server is.

Deep hardening is easier said that done, but still we can at least do the most obvious things like to remove unnecessary user accounts, software component, to limit the user population freedom to use certain services and utilities (for example su), adopt one time passwords (SecureID is OK but rather expensive), improve access controls (including user and group rights), chroot some applications (chroot is a small, easily checkable tool; the big advantage of a chroot cage is that you can take away almost all of the OS and leave a very small, extremely restrictive set of tools there for applications you do not trust much) and so on. In Solaris 10 zones provides additional capabilities of compartmentalization of OS. 

Return on investment of fashionable or non-fashionable security tools

Qualifications of the administrator usually represents an implicit limit on the level of hardening that can be achieved without disrupting functionality and getting into negative returns on investment. But generally increasing the security of the system presuppose usage of several security tools like hardening scripts, integrity checker, log collector (in most primitive form it can be just remote syslog) and log analyzer, and may be even simple (preferably very simple) intrusion detection. The latter has two forms "host-based" and "network".

The important point advocated in the paper is that positive return on investment in security tool is not given. While host based integrity checkers can, with some effort, provide a positive return on investment, network IDS are generally not very useful to say the least (network IDS may actually be harmful as it usually trigger too many false positives that after some times are all ignored; rephrasing Marx, network IDS is "an opium for upper management" (or SOX compliance, if you wish :-).

All those additional tools are separate topics, anyway, and we have additional pages devoted to them.  Here we discuss the general problem. But please be aware that return on investment on fashionable security tools is not given. It is very easy to buy expensive over hyped junk and most players in this field are well trained to help you in this noble exercise. See for example "virus hype" page that is reasonably instructive for the scenarios that can happen with naive security enthusiasts in hands of crooked security company salesmen. 

Typical Roles Used in Hardening

Typical roles used in hardening usually include (but are not limited to):

1. a firewall,
2. a web server,
3. a database server
4. mail server
5. dns-server
6. application server or other limited purpose servers, for example:
   • web application server, like Webshere
   • SAP/R3 server

Seldom one can see a critical evaluation that openly states that such-and-such security tool is a dinosaur that lost all practical value several years or even decades ago and such-and-such is badly written and has poor architecture. The reader often needs the ability to read between the lines and if the source is available, analyze the source to get the idea of "what is what".

Talking about different flavors of UNIX it's clear that they are not created equal: have a very high respect for OpenBSD approach and that's what we should probably try emulate in Solaris environment.  

The author feels that there is still a shortage of good Solaris hardening tools, but also (and what is more important) a shortage of highly qualified Solaris administrators. Security is usually a battle on two fronts: you fight both an external enemy and an internal enemy at the same time. And the internal enemy is not only what is usually called "insiders."  It is often sysadmins themselves (we met our enemy, it's us :-), especially those who reached or exceeded their level of incompetence (see Peter Principle for details). 

There are a couple of decent existing tools for Solaris hardening (Titan, Jass, RQ-Kit) but all of them are still pretty raw and require an excellent knowledge of Solaris to be implemented properly. That actually might be a good thing: there is not and never will be "An Administering UNIX Security for Dummies".  And in the age of outsourcing this is a good news for both highly qualified system administrators and, on the other side appliance makers and appliance market ;-)

The Problem of Human Factor

IMHO the minimum amount of such people in corporate IS is usually proportional to the at least a square of the company revenue in billons (government is a special case ;-). And it's this internal enemy that represents real "fifth column" in computer security, the problem that should not be underestimated.  As Richard Forno aptly noted in one of his SecuryFocus columns "much of what constitutes the 'cyberterror threat' comes down to the poor management of systems critical to the security and viability of the United States."

An often overlooked fact is that Unix is too complex an OS to be administered by dummies.  Idiots sysadmins ( I mean here an incompetent sysadmin, who is not interested in Unix and does not work on improving his/her level of understanding of the system (an official definition "...a cretin, morpohodite, or old COBOL programmer selected to be the system administrator by a committee of cretins, morphodites, and old COBOL programmers." :-) by themselves are the biggest security risk to the system they administer, IMHO much bigger risk than hackers...

I can even reformulate this idea as "Softpanorama First Law of Hardening":

The level of security of any Unix environment can not be significantly different from the level of qualification of system administrator(s) responsible for this environment...

And you can easily guess The Second Softpanorama Law of Hardening:

If a large discrepancy between the level of qualification of system administrator(s) and the level of hardening of the system exists, the main trend is toward restoring equilibrium at some, not so distant, point...

It is important not to underestimate the human factor while working to improve the security of your intranet:

• Lack of Planning or Procedure: In the absence of security policy, many departments or workgroups will implement their own security measures. Without a formal plan, these measures can be counterproductive, inefficient, or unknowingly create security breaches.
  
• Lack of Follow-Up: Even the best security measures require maintenance and follow up, yet often the staff members or services organization that installed the security technology has moved on to other tasks. Reviewing log files for possible breaches and installing patches to applications and operating environments are two ongoing tasks that are often fall into background with time. A cruel joke is that the usefulness of network IDS for any particular organization is limited to the first week after the installation contains a lot of truth (here the problem is both with IDS itself and followup ;-)
  
• Willingness to Help: Surveys show that employees across the company, from administrative assistants to executives, will often hand out passwords to co-workers who request it, or to anyone on the telephone asking for one. Products such as token cards can prevent this; training and awareness programs can help too.
  
• Unwillingness to Follow Procedure: Some users will resist following newly established procedures. Usually, they don't fully comprehend the ramifications of not following the procedures, or cite business emergencies or how inefficient the security is to their job.
  
• Ego: Some employees or companies may claim they don't need assistance in creating and implementing an intranet security policy. In extremely rare exceptions, this may prove to be true. However, in practice the only people with comprehensive and current knowledge of how to protect IT systems are the people whose full-time job it is.
  
• Zeal: Some security policies and implementations create too much security, which can be expensive to install and reduce productivity. Creating burdensome security procedures may cause some users to try and subvert the established policies and procedures because they are too cumbersome.

That actually means that learning of Solaris as a (very interesting) OS is probably the first and most important task that needs to be addressed. Not installation and running of some fancy security tool (or two), but general level of understanding of Unix in general and Solaris in particular is the most critical security resource. 

Only those, who really understand "what is what" in Unix in general and Solaris in particular can successfully minimize their systems and understand compromises that are always involved in disabling services, changing settings and permissions recommended by hardening tools.  There is no free lunch and tighter security makes the system less and less usable which in real world translates into "everybody uses root" situation which in turn completely defeats the measures implemented. So finding a point where to stop is very important. Too much security can be counterproductive and very harmful. Please keep in mind there are sadistic sysadmins and security analysts who use security to torture users just to increase their social status.

Hardening as Minimization

I would like to reiterate it again and again that the idea of hardening is very simple: that's the idea of minimization of components by converting a general purpose OS into and appliance.  But the real world application of this simple idea is pretty tricky :-). There are many levels on which this can be done and there is a subtle interaction between those layers. Also return on investment is unclear and it's important not to overdo the thing: I would like to remind that you pay with the flexibility for deeper hardening.  There is approx seven major areas that require close attention. Among them:

1. Patching and controlling the patch level to all systems
   1. OS level patching. Patching does not affect flexibility of the system and as such represents one of the most important component of hardening.
   2. Application level patching (often overlooked). You can spend too much time and effort of securing your OS but if application is vulnerable that efforts are wasted. Security is as good as the weakest link and  more often then not application layer is the weakest link.
2. Logging
   1. Implementation of centralized logging
   2. Deployment custom automatic log-analysis tools (might be integrated with integrity checking software or standalone)
3. OS-level hardening. It's important not to overdo it as blocking really important services might contribute little to the improvement of the security but a results in a tremendous loss of flexibility. Typical example is R-services on internal boxes. It's easy to remove them as "security fashion" dictates. But if you do not replace them with ssh and use telnet/ftp pair instead the question arise: "Do you really gain enough in security to justify severe restrictions in flexibility?"  IMHO without replacement by ssh it is a questionable move, as close to  "pseudo security" as you can get, as such decision complicates administration and as such lessen transparency and security.
   1. Minimization of the number of packages used and installed software (JASS provides some help in this area).
   2. Configuration files and startup files (RC-files). Minimization of the number of daemons and ports used.
   3. Setting more restrictive File and directory permissions (it's important not to overdo it)
   4. Operating system kernel hardening
   5. Filesystems and mounting
      1. Mounting nosuid  as many filesystems as possible (/export/home is an obvious candidate).
      2. Usage of  read-only filesystem (/usr is an obvious candidate if /usr/local is symlinked to /opt) or even a duplicate read-only filesystem that are protected by write protection of SCSI-drives and serve as a reserve image for, say, /usr partition or other partitions. Actually a separate 9 gig harddrive is usually adequate for the /usr subsystem on boxes that need to be really secure.  You also can mount /usr susbsystem as read-only (JASS does this trick), but please move /use/local to /opt then.
          
4. Authentication level hardening
   1. Minimization of users, groups and, especially, users that are using weak (password-based) authentication
   2. Blocking any direct logins to system accounts including root (getting to root via su actually doubles the length of the root password, which is a very goos thing).  Limiting accounts that can su to root (wheel group in BSD) is another good thing.
       
   3. Usage of token IDs or one time passwords.
       
   4. Usage of PAM that prevent weak passwords (this is probably the best measure if it is not overdone).  Mild requirements, like at least one digit or delimiter in the password, no username, first name, etc are the best. Random passwords are actually counter-productive and in reality are less secure then words from the dictionary, if the OS uses shadow password file (except older version of HP-UX all major flavor of Unix use it now). If password stored in the shadow file, then the real question is not whether you can break a password using a standalone cracker and, say several millions attempts, but can you break it using a small series of  3 to 5 attempts (if, of course the account configured correctly and is disabled after, say, five attempts for at least an hour). So the requirement to have complex passwords in most cases might be counterproductive and raise number of helpdesk tickets without adding anything to the real level of security, as users tend to write such passwords in most unsuitable for storage of passwords places :-). And mnemonic passwords, including words from the dictionary are OK (or, better, AOL scheme - two short words from the dictionary separated by some delimiter): they are impossible to break in 5 * N attempts, where N is probably less then 100.  I often see   audit firms plays this game with less technically sophisticated customers. Instead of doing some useful, but more complex job they do an easy bur presentable one: they take your shadow file (often via insecure data collection package ;-) and run a password cracker (often offsite which is a gross violation of security).  That is not an exercise one  needs to pay any money ;-).
   5. Creation of an organization-wide naming system and uid/guid distribution system (permits additional logical security checks as well as helps to avoid nouser/nogroup files after file transfer)
       
5. Application-level hardening
   1. Restrictions on scripting. Minimization of the number of shells, scripting languages and similar applications and additional restrictions on the scripting, Removal of useful, but complex and potentially breakable supplementary packages like Answerbook 2 (but removal of man pages is a stupid idea).  Using born shell to root is a questionable idea: ksh is a better deal from the point of view of administrator productivity and does not have much lower security.
   2. Hardening of the configurations and patching of all major applications installed (WEBserver, database, application server, etc)
       
6. Installation of  integrity checking software
   1. Regular MD5 checking of key files via cron job (using some Perl script or, in worst case Tripwire)
   2. Periodic MD5 of other maps of all executables and key config files
   3. Systematic usage of configuration maintenance tools (CVS, etc) for maintance.
       
7. Networking level hardening
   1. Minimization of networking services
      • RC started daemons
      • inetd services
      • hardening of configuration files
      • misc TCP/IP security tricks
   2. Installation of xnetd or TCP wrappers (TCP wrappers are included in Solaris 9 -- better late than never ;-)
   3. Installation of Sunscreen Lite of other local firewall to limit open ports for running services.
   4. Securing remaining services (for example SNMP, DNS, SMTP)
       
8. Misc security tricks (MD5 database, integrity checking of critical and rootkit-related files, usage of burned CDs as read-only volumes, configuration control via CVS, etc.)

Again I would like to stress, that generally the security of  a Unix server(s) is proportional to the qualification of the sysadmin. Moreover naive hardening can lead to completely unusable box and make damage that  a hacker can only envy ;-) That's why so many sysadmin are afraid to start. And that's why in many cases Solaris servers that perform critical functions are running AnswerBook2, etc.

Good security is the art of compromise. Sometimes when usability can be negatively affected, its wise not to go too far and settle for a middle ground, preserving some services and blocking access to then from external sites via router a firewall. Please understand that many "security-related" recommendation are questionable (or even wrong), unless implemented correctly. 

Sometimes due to complexity security solution became a source of problems. Just think that most external exploits for ISPs a couple of years ago were related to openssh vulnerabilities. Hopefully this is a thing of the past, but its unclear whether those who use encrypted channel (VPN) with regular r-commands were more secure or less secure then users of ssh.  Similarly there were nice abuses of misconfigured proxy, especially appliances like Cacheflow (that are often a part of the security infrastructure). See also CacheFlow CacheOS Cross-site Scripting Vulnerability . They can improve security, if correctly configured, patched, architected, etc. But so are simpler solutions. For example I saw solutions that use expensive Cachflow boxes to speed up Internet access to several locations from the central location (corporate headquarters), while each of those (geographically distributed) locations might be better off using its separate (local) Internet connection instead of being fed from internal corporate network.

Sometimes installing a additional switch on DMZ can help to be less paranoid about less secure services that developers demands, especially in combination with TCP Wrappers. Anyway if some hardening trick badly affect functionality you should always critically access the return on investment using common sense, your knowledge of Solaris and application affected, best papers on the subject and, again, common sense. The goal of security is not to eliminate both risk and business ;-)

If you need really deep hardening,  you might be better off  using instead Trusted Solaris 8 or Solaris 10 (with zones). Tsol8/9 has some security extensions to cover the needs for separation of data in a highly secure environment e.g. mandatory access control, elimination of root, labeling. It's a better approach then trying to achieve the same from regular Solaris installation no matter how hard you try.   

Hardening Scripts Should be Heavily Customized
in Order to be Really Useful

Both Titan and JASS are regrettably are written in Born shell and are extremely simplistic. IMHO Perl is a much better tool for writing such scripts and it can raise the level of the functionality of the tool without making the source twice longer. IMHO at least dtksh (or ksh93 on Linux and FreeBSD) should be used instead of Borne shell. Perl tools theoretically can be much more powerful and elegant. But there might be a deeper problem: after some simplistic general procedures there is not much that general hardening script can do. That might explain why existing Perl hardening scripts for Linux are even worse than Solaris hardening tools in Born shell. For example, Bastille (a super hyped hardening tool for RedHat and Mandrake distributions) is simply weak and one should never study it as an example of Perl programming in this particular area ;-).

We can also distinguish  between scanners that perform checks in isolation from all other checks and more comprehensive scanners that understand what to check.  For example if  ftp or UUCP service is disabled it makes no sense to check or report ftp or UUCP vulnerabilities. The tool just needs to recommend to change permissions for the non-used executables  to 000 or something like that or  delete these redundant files from the system (here a packaging tool might be useful).

A separate task that should be performed by the separate set of tools is so called "integrity checking."  It gives the possibility to record the identity of critical system files including location and permission structure (including all-important SUID/SGUID files) and thus overlaps with hardening. It's not covered here. See Integrity Checking page  for some advice.

Final Warnings

The real test of hardening skills is to know were to stop. The paper proposes several laws of hardening that define the evolution of of the security of a particular system:

Softpanorama First Law of Hardening:

The level of security of any Unix environment can not be significantly different from the level of qualification of system administrator(s) responsible for this environment...

Softpanorama Second Law of Hardening:

If a large discrepancy between the level of qualification of system administrator(s) and the level of hardening of the system exists, the main trend is toward restoring equilibrium at some, not so distant, point...

Softpanorama Third Law of Hardening

In a large corporate environment incompetent people implementing security solutions are a bigger problem that most OS security weaknesses.  The real computer security skills presuppose not only the knowledge of what should be done, but the knowledge were to stop. The latter skills are completely lacking in wanna-be security specialists. If incompetents happen to be in charge of security one should expect that they will implement the most destructive for corporate IT measures  dictated by the current fashion, driven by excessive zeal and desire to survive.

Here are several other things that I think are important in no particular order:

1. You should never trust anyone's advice or security tool advertisement without a lot of  critical thinking.  Consultants are often biased and blatantly incompetent: security professional services are often dumping grounds for people useless in other departments of an organization (thing about cleaning services recruitment problems). Vendor tools advertising is very often blatantly overstate the usefulness and understate negative side effects of a particular tool. Some of then are applicable to your environment, but some might be definitely counterproductive. You should not try to be holier than Pope (or try to apply a firewall hardening policy to an non-critical internal server :-). But the sad truth is that in a large corporate environment this is, unfortunately, an most easy and politically correct path. At the same time excessive security/hardening zeal is a very dangerous thing and it can easily put your company in such a disadvantage that any measures to improve IS will simply never work ;-). For example I suspect more servers were hosed by, say, misapplication or overzealous application of hardening scripts, say, Titan  then hackers; I did it a couple of times myself ;-)
    
2. Like for any book of recipes or guide to successful living you should know that most security advices are simplified answers to complex questions and you should treat them as such. They might be naive (and this is the level of a lot of security papers ;-), and thus not be applicable to your particular situation or worse can be outdated, incorrect and even harmful.
   
   You should use tools that permit you to create your own hardening policy and you do need to understand what each script is doing while writing such a policy. Again, you should never accept and use a recommendation without thinking carefully and critically first!  Too much  (stupid) seal in security is more dangerous that any hacker. An idiot with the security initiative can paralyze the organization pretty quickly. Sometimes even sound recommendations can be not that sound in real-life environment ;-) For example if X is blocked by a firewall than the security gains from killing X environment are less and might not outweigh losses of productivity... Also in many DMZ situations with strict routing and switched segments the risk of eavesdropping is much less than other risks and SSH just adds additional complexity. Password protection policy is also non-trivial thing. See for example Slashdot The Psychology of Passwords. I would repeat it again: if somebody can steal your shadow file with encrypted passwords and you have more than a dozen of users, then most probably you are a toast anyway, so why to increase the level of hate toward security (and the number of helpdesk tickets).
    
3. There is no substitute for real understanding of the OS and infrastructure. Security tools is just extension of your knowledge, not a substitute for it. The present level of development of hardening tools still is far from the "idiot-proof" level and with the complexity of tasks that they solve I doubt that they will mature to the level of  "run and forget" in the foreseeable future. If you do not understand the tool and the reasons and consequences of the action of a critical modules of a hardening package you can destroy your system more effectively that any hacker. I know because I did it several times using Titan on Solaris ;-) Probably a lot more systems were destroyed by sysadmins that try to apply hardening scripts without bothering to understand what exactly they are doing that by hackers  :-). Also Unix is an old OS and there are a lot of legacy staff in each distribution that presents a danger because of their obscurity. For example who is still using UUCP ? But the package is present in most Solaris installations I saw. And it is still a security danger as anybody who knows UUCP really well can attest.
    
4. There is no substitute for real understanding of applications you are running. Most of the threats we're seeing today are attacks on applications. Even such traditional points of attacks often discussed/hardened on OS level despite the fact that DNS server, WEB server or FTP server or Telnet server are essentially applications. Hardening of applications is different from hardening OS (unless you can disable the application in question) and more complex (or to be precise less studies and more cumbersome). One of the most common types of attack is I personalization, where somebody first breaks into legitimate user account and then try to extend his access into other users accounts and steals as much information as possible via their network identity is usually performed on the application level. That's one of the most common attack that one should expect at the application layer  (for example via fake email to the user with the request to confirm some data and fake form that mimic actual authentication form) and take measures to prevent it harden the applications (both application server and database server) against it.  For example a nice and simple precaution would be a statement on the authentication page that in no case this or similar authentication form can arrive in a email.
    
5. Working with vendors that try to sell you security products please remember about Technobabble

If the vendor's description appears to be confusing nonsense, it may very well be so, even to an expert in the field. One sign of technobabble is a description which uses newly invented terms or trademarked terms without actually explaining how the system works. Technobabble is a good way to confuse a potential user and to mask the vendor's own lack of expertise.

And consider this: if the marketing material isn't clear, why expect the instruction manual to be any better? Even the best product can be useless if it isn't applied properly. If you can't understand what a vendor is saying, you're probably better off finding something that makes more sense.

6. The main enemy is within and often it's you ;-).  The main problem is not a "uberhacker" breaking into your site (most hackers are much less technically sophisticated than it is assumed in the security literature and pray for easy targets; BTW that makes UltraSparc Solaris 10 much less vulnerable that Intel-based systems), but some stupid blunders on the part of sysadmin that makes site vulnerable to script kiddies and insiders. That means that checks need to be periodical and that security is a continuous (and rather boring) process much like cleaning the house. Also patches need to be applied of a regular basis and they often change permissions, rc scripts, etc from previously hardened state to the "natural" state. The means that periodically you need to perform "re-hardening" of the system
    
7. Unix may be insecure, but applications are even less secure than Unix. Web server misconfigurations, vulnerable CGI scripts, junk programs written by programmers who might be better choosing other occupation, blunders in writing complex applications like WebSphere (where left hand does not know what the right hand is doing ;-) etc. are a large part of the security risk and need to be treated with due attention. This topic is covered elsewhere.
    
8. It is important not to underestimate the human factor while working to improve the security of your DMZ or intranet:
    
   • Zeal: Some security policies and implementations create too much security, which can be expensive to install and reduce productivity. Creating burdensome security procedures may cause some users to try and subvert the established policies and procedures because they are too cumbersome.
      
   • Ego: Some employees or companies may claim they don't need assistance in creating and implementing an intranet security policy. In extremely rare exceptions, this may prove to be true. However, in practice the only people with comprehensive and current knowledge of how to protect IT systems are the people whose full-time job it is.
      
   • Lack of Planning or Procedure: In the absence of any formal policy, many departments or workgroups will implement their own security measures, or modify the intranet to address their business needs. Without a formal plan, these measures can be counterproductive, inefficient, or unknowingly create security breaches.
      
   • Unwillingness to Follow Procedure: Some users will resist following newly established procedures. Usually, they don't fully comprehend the ramifications of not following the procedures, or cite business emergencies or how inefficient the security is to their job. Training can help overcome some of these objections, and a well-designed security mechanism with the latest technologies should add little, if any, burden once fully implemented.
      
   • Lack of Follow-Up: Even the best security measures require maintenance and follow up, yet often the staff members or professional services organization that installed the security technology has moved on to other tasks. New hacker tools are being created, and new "holes" are being discovered on a regular basis. Reviewing log files for possible breaches and installing patches to applications and operating environments are but two of the ongoing tasks required to maintain a secure environment.
      
   • Willingness to Help: Surveys show that employees across the company, from administrative assistants to executives, will often hand out passwords to co-workers who request it, or to anyone on the telephone asking for one. Products such as token cards can prevent this, but training programs throughout the company are needed to teach and reinforce the value of good security.

Webligraphy

[Bezroukov2005a] Solaris vs Linux Security in Large Enterprise Environment

[Bezroukov2005b]  Softpanorama (Slightly Skeptical) Sun Solaris Security and Hardening Page