|
|
"Security is a process, not a product." This statement, attributed to security guru Bruce Schneier, well introduces the process life cycle–based approach to security that is necessary to provide a living, iterative framework for information security management. The main parts of such a life cycle are prevention, detection, reaction, and deterrence. This framework is defined by security policies, procedures, guidelines, and standards. For security policies and procedures to be effectively and efficiently set and implemented, management and staff security awareness is necessary. Issues affecting physical, platform, network, applications, and operations security must be known and understood. This chapter builds on the knowledge gained from the previous two chapters and concludes Part I of this guide.
Before we discuss the security life cycle and its constituent steps, you must remember that to secure its information and information processing resources, real commitment from an organization's top management is necessary. Security requires business-wide changes in processes, habits, and approaches that would not happen without management's full understanding, agreement, and commitment. Although it is outside the scope of this book to cover methods of building a business case for information security and obtaining management support, information security practices in the organization must be aligned with the organization's business goals. Information security should not and cannot be an isolated mission—its purpose is to protect the organization and its business from risks, taking into account the environment in which the organization operates and the specifics of its business and industry in a cost-effective manner.
Accepted standards and frameworks, such as ISO 17799 (Code of Practice for Information Security Management), COBIT, and others should be considered and used if appropriate, with information security management being interwoven into the fabric of business decisions and operations. This, of course, requires a good level of information security awareness throughout the organization at all levels, which may be expected only if the organization provides suitable and regular security awareness training at both management and staff levels. The security policy is the high-level document or set of documents that in particular identifies the information assets of the organization, stipulates who owns them, indicates how they may or may not be used, and sets requirements for their use along with sanctions for misuse.
In Chapter 1, we stipulated the importance of not only preventive security controls but of detection, response, and deterrence. Without any one of these parts of the life cycle, the security controls would be incomplete and lacking. It is important to state that this life cycle approach to security is applicable in all cases, whether you are securing an enterprise by defining security policies and procedures, a network by means of authentication and access control mechanisms, or a Solaris server by using secure configuration practices and security tools. In all cases, the life cycle process is the same—prevent, detect, respond, and deter—and then the cycle repeats, keeping in mind the lessons learned.
Preventing a problem from occurring is very often much easier than sorting it out after it has happened. However, circumstances outside of your control may make preventive measures ineffective or impossible. Preventive security controls may also negatively affect availability, performance, or staff acceptance of security measures. This all means that although preventive controls should be the first ones to be considered, they are by no means the only controls you should consider. Examples of preventive controls include firewalls, logical and physical access control systems, and security procedures that are devised to prevent violations of security policy to occur.
Detection mechanisms serve not only to detect failures of preventive security controls—which is perhaps their main function—but also to provide a degree of assurance by demonstrating when the preventive controls are indeed operating and functioning as expected. When considering detective controls, it is imperative that you realize that in certain cases, detection has its restrictions as well. In particular, with regard to software vulnerabilities (bugs), testing and verification cannot prove the absence of bugs. What they can prove is that after so much testing, only some of the bugs were found.
Obviously, because only discovered security breaches may be analyzed and countermeasures against future occurrences devised, detection controls are very important. To employ preventive security controls and ignore detection issues is unacceptable; this may result in a false sense of security, which sooner or later will be exploited. Detection controls should always follow preventive controls and include network and host intrusion detection systems, physical movement and intrusion detection systems and alarms, and cryptographic checksums on transmitted information (to detect unauthorized modifications).
As with prevention and detection, detection and response are bound together. What use is detection if you do nothing about the detected events? Incident response is actually a subdiscipline of information security; it is the formal set of defined and approved actions based on the information security policy and best practices that are to be taken in response to a security incident. It may cover what to do in case of incident, who is to do it, how to do it, when to do it, whom to inform, what may go wrong, how not to create more problems, how to collect and preserve evidence for possible legal actions, and how to minimize damage after the incident took place. Some large organizations may benefit from an entire department, a corporate Computer Emergency Response Center (CERT), taking care of incident response issues.
Deterrent controls may potentially be confused with preventive controls, and although both types of controls aim to preclude security violations from happening, they try to do so at different times. While preventive security controls try to prevent a breach of security after the adversary has decided to attack but before the attack has succeeded, deterrent controls try to discourage the attacker from attacking in the first place by demonstrating that the attack is not going to succeed; and even if it does, it will be detected and dealt with. Deterrent controls may take on many different faces—such as good information security management, regular audits, security-aware staff, well-administered systems, good employee morale, and security certifications. All of these deterrent controls serve to put off potential attackers; they basically send the message that the organization is prepared, able to defend itself, and knows what to do to stop you.
The key to correct application of the security process life cycle is to realize that it has to be an iterative, feedback-driven, living process. After every step, the entire process should be evaluated to identify weaknesses, address them, document them, and proceed to the next step, in a never-ending, continuous process.
In Chapter 2, we identified security awareness as the best defense against social engineering attacks. However, the benefits of having security-aware staff and management do not stop there. Needless to say, security-aware employees are the best partners of the organization and its information security efforts, while staff members who have no idea about security practices or simply don't care are not partners at all. One doesn't need determined adversaries to suffer a security breach—a clueless insider who doesn't understand the consequences may expose the organization to risks that could otherwise be avoided.
When it comes to security awareness training, remember that management and staff training resources may and usually will differ in scope and content; however, certain aspects stay the same. The most important of them is the regularity of training: security awareness should not be a one-off project but should take the form of regular (for example, quarterly) meetings that would remind the audience of risks, update them on the latest developments and events, and reinforce the organization's security policies and procedures.
Management needs a high-level, big picture of security risks, threats, and vulnerabilities, which takes into account industry specifics and regulations as well as the organization's business objectives and resources. While managers are information systems users just like others in the organization, their decision-making responsibility extends over a wider area than those of non-managerial staff; therefore, they need a greater understanding of security concerns. The format of training aimed at management also should support the goal of delivering management-oriented security awareness training that is seen as time well-spent and not as a nuisance. Staff security-awareness training, in contrast, does not need to be wide in scope but should address issues that are widely seen and pose the most risk, such as social engineering, malware, and password management. Staff should be encouraged to participate in the process by sharing their experiences and good practices.
There can be no information security management without defined, written, and communicated information security policies, procedures, and guidelines. It is important to understand the relationship among these documents and their objectives, as well as the significance of communicating these objectives throughout the organization. These may include such mechanisms as logging and auditing, system software maintenance, patch management, and configuration and change management.
Security policies are to be set by management and are high-level in nature. They specify what should and should not happen, without going into detail regarding how to reach these goals. Security policies should be sufficiently specific to convey their meaning and objectives unambiguously, but at the same time general enough not to require modification every month or after introduction of a new system or application in the organization. Security policies may be thought of as one of the mechanisms that define and convey the information security requirements of the organization's management to the staff of the organization.
Security procedures are developed within the organization by subject-matter specialists with the assistance of security professionals and/or information systems auditors. Because security procedures are usually highly specific and technical in nature, they should be developed by those who appreciate these considerations. Procedures may be application-specific and/or version-specific and need to be kept current with the information systems environment of the organization. System and security administrators play a key role in developing and enforcing security procedures.
Security guidelines are nonbinding recommendations that focus on how to develop, define, and enforce security policies and procedures. Although these guidelines are nonbinding, it is customary in an organization to require explanation from those who choose not to follow them; this practice acknowledges the fact that something that is appropriate in most circumstances is not necessarily appropriate in all circumstances and that staff should have the option of not following guidelines, if justified.
Unlike guidelines, security standards are mandatory, either because they are dictated by the security policy, law, or regulations or because the entity in question has decided to adhere to the standard. Examples of well-known security standards are ISO 17799, Code of Practice for Information Security Management, and ISO 15408, Common Criteria for Information Technology Security Evaluation, which are discussed later in this chapter.
Physical security addresses the physical vulnerabilities, threats, and countermeasures used to control risks associated with physical destruction; unauthorized access; loss due to theft, fire, natural disasters (floods, earthquakes, tornados), or environmental issues (air conditioning, ventilation, humidity control); and all associated issues. Physical security is the foundation of all other aspects of security and a basic requirement that must be addressed, because without physical security, most if not all other areas of security become irrelevant. To take care of physical security properly, the following physical security issues should be considered and appropriate policies set, which may define the location of assets, what access and to whom it should be granted, and on which basis access should be granted.
When choosing a facility that will house information systems, it is important to remember some guiding principles. Although in many cases the IT or information security department of the organization has no control over such aspects of the facility as location or type of building materials used, it is nevertheless useful to know what issues affect physical security of the facility. The first issue to consider is whether the facility is potentially vulnerable to devastating natural disasters such as floods, earthquakes, or tornadoes. Risk assessment of a facility's susceptibility to these disasters should take into account the location of the facility and historic information about these disasters, such as those provided by insurance companies and weather monitoring services. Next, the surrounding area, road access, and proximity to fire, police, and medical facilities should also be considered when assessing and analyzing physical risks.
After a suitable facility has been chosen in which to house information systems, it should be secured to provide physical access control and monitoring. A security perimeter should be defined and indicated, which would divide the territory into "inside," "outside," and "buffer zones." Physical security, access control, and monitoring objectives should be set and implemented using appropriate controls, such as secure locks, closed-circuit cameras, and motion detectors. All these mechanisms should implement the high-level physical security policy, which may be a separate document or form part of the organization's information security policy. Procedures should be developed for such operations as granting access to a facility, changing access privileges, and terminating access. Universal security principles, such as principles of least privilege and compartmentalization, should be employed in physical security controls as well.
Fire is perhaps the most important physical security risk that should be assessed and controlled. Fire has the potential to destroy not only an organization's facilities, information systems, and data, but it can also affect the most important asset of any organization—the human worker. Therefore, fire prevention, detection, and suppression systems must be in place throughout the facility. Various types of fire prevention, detection, and suppression mechanisms exist; depending on the size and requirements of the facility, the organization should choose the most appropriate system. All systems should also comply with local fire regulations, and fire insurance should be in place to cover losses from fire, should the prevention and/or detection mechanisms fail.
Although modern information technology equipment is not as environmentally demanding as it was several decades ago, it is still necessary to provide appropriate environmental conditions not only for the computer hardware but for its human operators and users as well. This is especially relevant for areas with relatively high humidity and/or a hot climate. Environment control should ensure that humidity stays within acceptable levels (between approximately 45 and 60 percent) and that indoor temperature is around 70 degrees Fahrenheit. Ventilation is also required for manned facilities and offices. Country-specific regulations usually govern the mandatory health and safety requirements that would apply to such facilities. Adequate mechanisms (such as line conditioners, uninterruptible power supplies, and backup generators) should also exist to shield against electrical power fluctuations and outages that may either interrupt operations or cause permanent damage to equipment. Lightning protection and grounding should also be installed and tested as appropriate.
Security of a particular computer platform depends on the security of its three parts, which make up the platform itself: the hardware, firmware, and operating system. Depending on the particular platform used under the Solaris 10 platform, security of the system will also vary due to differences in hardware and firmware between supported platforms.
As you know, the Solaris 10 operating environment is available for SPARC (Scalable Processor Architecture), IA32, and AMD64 computer architectures. From the beginning, SPARC was designed for multi-user, multi-processor server systems, whereas the IA32 architecture began its life as primarily a personal computer architecture. Although IA32 has seen many modifications and improvements over the years, SPARC has some features that are not provided by IA32. One of the features that directly affects security is the ability to disable the execution of code in a stack on SPARC systems.
The OpenBoot firmware used on SPARC systems is a flexible, full-featured, standards-compliant firmware environment that includes two-level password protection and a user-definable maximum number of incorrect password attempts.
As you will see later in this book, Solaris 10 has a solid set of security features and tools that are among the best available in modern operating systems. These include such vital functions for a multi-user network operating system as auditing, role-based access control, pluggable authentication modules, and compartmentalization.
Network security is a term that covers a myriad of security issues, technologies, and mechanisms at the physical, data link, network, and transport layers of the ISO Open Systems Interconnection (OSI) reference model. As such, network security is not platform- or operating system–dependent but instead covers the security of protocols and network mechanisms. Although system-level security issues such as buffer overflow vulnerabilities are often described as network security issues, this is not actually the case. In the chapters that follow, you will see how to use the network security features of Solaris 10 to increase network security. One of the tools used to control TCP/IP options can be used to modify various networking stack options to suit particular environment or security requirements.
Network security considerations at the physical layer differ for wired and wireless networks. In wired networks, physical access to cabling may be controlled; whereas in wireless networks, such as those based on the IEEE 802.11 standards, this is either impossible or infeasible because of their very nature. This means that physical security strategies in these two cases have to be different: wireless networks may not rely on physical access controls but must instead provide security at higher layers, such as the data link, network, transport, or application layer.
The concept of availability also takes on different meanings in wired and wireless networks: availability of wired networks may be affected only by cut or damaged cables, whereas availability of wireless networks is easier to compromise. Confidentiality and integrity of communications over wired networks may be affected by wiretaps. Fiber-optic cables are much more difficult to tap into than electrical cables, and they do not radiate information and are not susceptible to the noise, attenuation, or crosstalk problems that plague electrical cables; fiber-based wired networks therefore generally provide better physical layer security.
Network security at the physical layer also greatly depends on the network topology employed. The main types of network topologies are ring, bus, star, and mesh topologies. The most secure of these is the full mesh topology; because all systems are connected to each other, failure of any system or communication path will not affect communications between other systems. However, because of cost and implementation issues, full mesh networks are seldom used and may be used only in small networks. Star topology networks have a single point of failure—the hub, switch, or router—and, as you know, having single points of failure is bad for security. At the same time, having a single communications center makes the network easier to protect and manage than many distributed centers.
At the data link layer, network security goals are the same: confidentiality, integrity, and availability. These three goals may be affected by a number of considerations, such as the type of transmission (asynchronous or synchronous), media access technology (carrier sensing or token passing), existence of integrity checks (checksums), broadcast domains, collision domains, and whether hubs, routers, or switches are used. In switch- and router-based networks, frames are forwarded only to the destination device (unless the frame in question is a broadcast one, in which case it is broadcast in the broadcast domain). Confidentiality and availability in switched and routed networks is better protected than in hub networks for the following reasons:
Since the frame is delivered only to the intended destination, adversaries do not see it and therefore do not have a chance to compromise the frame's confidentiality.
Unlike hub-based networks, frames in router- or switch-based networks are not forwarded to all nodes, so network bandwidth and processing time at nodes are not wasted, improving availability.
Most modern data link layer protocols employ cyclic redundancy checksums (CRCs) to guard against data corruption in transit. Although effective against data transmission errors, CRCs do not prevent malicious modification of frames by an intelligent adversary. For these purposes, cryptographic message digest algorithms are used—namely MD5, SHA1, and HMAC.
Perhaps the most important security consideration at the network layer is the protection of integrity and availability of routing information and protocols, because routing is the main function at the network layer. Although smaller networks may use static routing and avoid using routing protocols at all, thus effectively avoiding any potential issues associated with routing security, networks of any substantial size need and use routing protocols to exchange network reachability and path information between routers.
Routing protocol security issues include the following, in particular:
Message origin authentication
Message integrity protection
Malicious router detection
Methods of checking reasonableness of routing updates
In many protocols, the first two concerns are addressed by using cryptographic message digest algorithms such as MD5 to authenticate routing update messages exchanged between routers and to detect any changes made to these messages after they have been sent by the source router. For instance, a standard and popular network layer security framework is the IP Security Architecture (IPSEC). Because IPSEC works at the network (Internet Protocol) layer, all layers above are protected by IPSEC's confidentiality, integrity, and authentication services.
In some situations, it is impossible or inappropriate to provide security at the network layer. In such cases, transport layer security mechanisms and protocols may be used. Two of the most widely employed transport layer security protocols are Secure Sockets Layer (SSL) and Transport Layer Security (TLS), often referred to as SSL/TLS. SSL/TLS uses strong cryptography to provide security to connection-oriented transport protocols such as the Transmission Control Protocol (TCP). Many secure protocols such as HTTPS, POP3S, and IMAPS use SSL/TLS.
Although security at the operating system and network levels plays an important role in any computing environment, a system may not be considered secure if the applications that run on top of these operating systems and networks are insecure. The domain of applications security is concerned with all life stages of computer applications, from defining requirements and drafting functional specifications to designing, coding, testing, installing, and maintaining applications. Increasing interconnection of previously standalone applications using technologies such as Web Services and Remote Procedure Calls (RPC) increase the need for security at the application level. In the past, applications were isolated and protected by physical and logical access controls, but today organizations are pressed to open up their systems for greater efficiency and new services.
With exponential growth of Web applications, the importance of applications security has reached new heights and requires the same process-based life cycle approach, also taking into account specifics of application development. Many standards, frameworks, toolkits, and methodologies have been developed to aid in secure software development, but as usual, good old practices, such as documenting applications and making realistic assumptions, can increase software quality and security.
The importance of applications security is further demonstrated by the fact that most security vulnerabilities in the SANS Top 10 list (shown in Chapter 2) are due to applications vulnerabilities, not weaknesses in the operating system.
|
|