I l @ ve RuBoard |
Computer protocols are well-documented to help with implementing them on differing platforms. These implementations are done by many people at many locations with differing skill levels. Some are implemented by students and others by hardware vendors . Some receive careful review while others have limited support. It is not surprising that the quality of implementations varies significantly. Known VulnerabilitiesMost successful attacks utilize known vulnerabilities. New exploits are continuously being discovered . They are documented and shared in the hacker community. They are addressed and repaired, but the patches are often not implemented on systems, so they remain vulnerable after the problem should no longer be a problem.
Initially UnsecureMany systems are shipped with security features turned off. This will often simplify the administration of the system and reduce the number of help desk calls. However, many administrators will be unaware that they need to do anything after the system is installed. The security implications are often not documented and the process of enabling the security features are not well-documented or easy to find.
Improperly ConfiguredImproper security configurations are responsible for a great number of system compromises. There are many reasons for improper configurations, including incorrect or incomplete documentation and under trained or nonexistent administration. Even automated administration tools have been known to improperly or inadequately secure an environment. Interactions between systems can lead to improper security configurations. Not all combinations or interactions are tested . Installing or configuring one system may alter the configuration file which is used by both systems. Services Which Are No Longer UsedThere are many protocols that are no longer in widespread use that are still installed on systems for compatibility. Many of these obsolete protocols predate any level of concerns of security. They may have been designed when direct connected or point-to-point dial-up access was the only available network. Many of these old protocols were migrated to LANs, but were not secured since they were rapidly replaced by newer protocols. Many computer vendors started with proprietary operating systems. These systems expanded into networking before standards were available. DEC created DECnet , Apollo had Apollo Token Ring (ATR), HP had its network services (NS), and IBM created a number of protocols. As each of these and other vendors moved into open systems, they had to implement the proprietary protocols on their open systems to allow connectivity. Many of these protocols are now obsolete but still exist in the versions of the UNIX systems from these vendors and are often installed and configured by default. Many of these proprietary protocols granted greater permissions with less authentication than current protocols. Many of these protocols were proprietary and are not widely known. The programs which support the protocols are not part of the normal network start-up routines. An administrator will have seen the process running on all the machines of this type and not know what it does, only that it is always there. Even the vendor's help desk may not know. In some cases, these protocols are enabled by default. Many of these early protocols have little or no security and may not be able to be adequately secured. Administrators may not know about them or what they are or what they do. As a system manager, you must know what is installed and configured on your system. These programs may appear as unknown entries in the Internet configuration file or as daemons that are initiated during system start-up. These programs should be removed from the system if they are not being used. You must know what all the processes running on your system do, and why they are there. |
I l @ ve RuBoard |