Network Security Concepts and Policies

This chapter is from the book 

Secure Network Lifecycle Management

The lifecycle approach looks at the different phases of security, such as assessment, testing, implementation, monitoring and so forth, to provide methodology in securing our networks. The roles of risk, regulatory compliance, and security policies in designing and building effective security architectures have been described. How are these three components related?

IT Governance, Risk Management, and Compliance

Organizational efforts for IT governance, risk management, and compliance (sometimes known as IT GRC) are often separated by department or regulation type within organizations. This can create many problems, including unidentified risks, redundancies, and higher costs, requiring more resources, time, and effort to achieve a secure IT environment that meets regulatory compliance requirements. Moreover, while business processes and business process improvements are common practices in most organizations, this approach is often missing in the area of security.

Today, organizations of all kinds are making a conscious effort to simplify the process, given the multiple places in which these three areas operate concurrently. The result is a more effective process of defining risk within the context of existing organizational rules and business objectives, and within the framework of compliance regulations, as shown in Figure 1-15. The IT governance component creates stringent requirements for information security architectures, within the goal of adding business value, in addition to mitigating risk.

This convergence results in an ideal framework and context to create a lifecycle approach to information security.

Secure Network Life Cycle

By framing security within the context of IT governance, compliance, and risk management, and by building it with a sound security architecture at its core, the result is usually a less expensive and more effective process. Including security early in the information process within the system design life cycle (SDLC) usually results in less-expensive and more-effective security when compared to adding it to an operational system.

A general SDLC includes five phases:

1. Initiation
2. Acquisition and development
3. Implementation
4. Operations and maintenance
5. Disposition

Each of these five phases includes a minimum set of security steps that you need to follow to effectively incorporate security into a system during its development. An organization either uses the general SDLC or develops a tailored SDLC that meets its specific needs. In either case, the National Institute of Standards and Technology (NIST) recommends that organizations incorporate the associated IT security steps of this general SDLC into their development process.

Initiation Phase

The initiation phase of the SDLC includes the following:

• Security categorization: This step defines three levels (low, moderate, and high) of potential impact on organizations or individuals should a breach of security occur (a loss of confidentiality, integrity, or availability). Security categorization standards help organizations make the appropriate selection of security controls for their information systems.
• Preliminary risk assessment: This step results in an initial description of the basic security needs of the system. A preliminary risk assessment should define the threat environment in which the system will operate.

Acquisition and Development Phase

The acquisition and development phase of the SDLC includes the following:

• Risk assessment: This step is an analysis that identifies the protection requirements for the system through a formal risk-assessment process. This analysis builds on the initial risk assessment that was performed during the initiation phase, but is more in depth and specific.
• Security functional requirements analysis: This step is an analysis of requirements and can include the following components: system security environment, such as the enterprise information security policy and enterprise security architecture, and security functional requirements.
• Security assurance requirements analysis: This step is an analysis of the requirements that address the developmental activities required and the assurance evidence needed to produce the desired level of confidence that the information security will work correctly and effectively. The analysis, based on legal and functional security requirements, is used as the basis for determining how much and what kinds of assurance are required.
• Cost considerations and reporting: This step determines how much of the development cost you can attribute to information security over the life cycle of the system. These costs include hardware, software, personnel, and training.
• Security planning: This step ensures that you fully document any agreed upon security controls, whether they are just planned or in place. The security plan also provides a complete characterization or description of the information system and attachments of or references to key documents that support the information security program of the agency. Examples of documents that support the information security program include a configuration management plan, a contingency plan, an incident response plan, a security awareness and training plan, rules of behavior, a risk assessment, a security test and evaluation results, system interconnection agreements, security authorizations and accreditations, and a plan of action and milestones.
• Security control development: This step ensures that the security controls that the respective security plans describe are designed, developed, and implemented. The security plans for information systems that are currently in operation may call for the development of additional security controls to supplement the controls that are already in place or the modification of selected controls that are deemed less than effective.
• Developmental security test and evaluation: This step ensures that security controls that you develop for a new information system are working properly and are effective. Some types of security controls, primarily those controls of a nontechnical nature, cannot be tested and evaluated until the information system is deployed. These controls are typically management and operational controls.
• Other planning components: This step ensures that you consider all the necessary components of the development process when you incorporate security into the network life cycle. These components include the selection of the appropriate contract type, the participation by all the necessary functional groups within an organization, the participation by the certifier and accreditor, and the development and execution of the necessary contracting plans and processes.

Implementation Phase

The implementation phase of the SDLC includes the following:

• Inspection and acceptance: This step ensures that the organization validates and verifies that the functionality that the specification describes is included in the deliverables.
• System integration: This step ensures that the system is integrated at the operational site where you will deploy the information system for operation. You enable the security control settings and switches in accordance with the vendor instructions and the available security implementation guidance.
• Security certification: This step ensures that you effectively implement the controls through established verification techniques and procedures. This step gives organization officials confidence that the appropriate safeguards and countermeasures are in place to protect the information system of the organization. Security certification also uncovers and describes the known vulnerabilities in the information system.
• Security accreditation: This step provides the necessary security authorization of an information system to process, store, or transmit information that is required. This authorization is granted by a senior organization official and is based on the verified effectiveness of security controls to some agreed upon level of assurance and an identified residual risk to agency assets or operations.

Operations and Maintenance Phase

The operations and maintenance phase of the SDLC includes the following:

• Configuration management and control: This step ensures that there is adequate consideration of the potential security impacts due to specific changes to an information system or its surrounding environment. Configuration management and configuration control procedures are critical to establishing an initial baseline of hardware, software, and firmware components for the information system and subsequently controlling and maintaining an accurate inventory of any changes to the system.
• Continuous monitoring: This step ensures that controls continue to be effective in their application through periodic testing and evaluation. Security control monitoring, such as verifying the continued effectiveness of those controls over time, and reporting the security status of the information system to appropriate agency officials are essential activities of a comprehensive information security program.

Disposition Phase

The disposition phase of the SDLC includes the following:

• Information preservation: This step ensures that you retain information, as necessary, to conform to current legal requirements and to accommodate future technology changes that can render the retrieval method of the information obsolete.
• Media sanitization: This step ensures that you delete, erase, and write over data as necessary.
• Hardware and software disposal: This step ensures that you dispose of hardware and software as directed by the information system security officer.

Models and Frameworks

The five-phase approach of the SDLC gives context to the process of designing, creating, and maintaining security architectures. It is based on NIST Publication 800-64 revision 2. Other frameworks and models exist, providing similar guidance to your security architecture:

• The ISO 27000 series is a comprehensive set of controls comprising best practices in information security. It is about information security, not IT security. It is also an internationally recognized information security standard, broad in scope and generic in applicability. It focuses on risk identification, assessment, and management. It is aligned with common business goals:
  • Ensure business continuity
  • Minimize business damage
  • Maximize return on investments

  ISO 27000 standards are much more commonly applied in commercial organizations than in government. Originally created as BS17799, this framework was first submitted in 1995, and revised in 1998, but was not adopted by the ISO until 1999. Significantly revised in 2005, it was formally converted to two related ISO/International Electrotechnical Commission (ISO/IEC) standards, 27001 and 27002.

• Control Objectives for Information and Related Technology (COBIT) provides good practices across a domain and process framework and presents activities in a manageable and logical structure. The good practices provided by COBIT represent the consensus of experts. These good practices are strongly focused more on control and less on execution.

  These practices will help optimize IT-enabled investments, ensure service delivery, and provide a measure against which to judge when things do go wrong. COBIT is generally considered complementary to ISO/IEC 27001 and 27002.

• The Information Technology Infrastructure Library (ITIL) was developed under the supervision of the Central Computer and Telecommunications Agency in the UK. ITIL is a set of eight practice guidebooks covering most aspects of IT service management. The fourth service management set is Security Management. ITIL Security Management is based on the code of practice in ISO 27002.

Table 1-7 provides a summary of the different frameworks.

Table 1-7. Comparison of Frameworks

Framework	Strengths	Focus
COBIT	IT controls IT metrics	IT governance Audit
ISO 27000 series	Global acceptance Certification Security control	Information security Management system
ITIL	Processes Certification	IT service management
NIST 800 series	Detailed, granular Tiered controls Available for free	Information systems FISMA (federal government)

Network Security Posture

By assessing all aspects of the networked business environment, it is possible to determine the ability of the organization to detect, defend against, and respond to network attacks. The following are the key activities:

• Security posture assessment (also known as vulnerability assessment): The first step in planning network security requires an evaluation of the network security posture of the organization. The security posture assessment provides a snapshot of the security state of the network by conducting a thorough assessment of the network devices, servers, desktops, and databases. The effectiveness of the network security is analyzed against recognized industry best practices to identify the relative strengths and weaknesses of the environment and document specific vulnerabilities that could threaten the business. Because network security involves all aspects of the business, it is necessary to assess security from various perspectives, including the internal, external, dial-up, and wireless networks, and to provide recommendations on how to improve overall network security.
• Internal assessment: With so much attention devoted to threats and incidents by hackers, administrators may overlook the security of the internal, trusted network. The internal assessment is a controlled network attack simulation that is used to gauge the exposure present on internal systems, applications, and network devices. The assessment identifies the steps that are needed to thwart intentional attacks or unintentional mistakes from trusted insiders to effectively secure valuable information assets. To go beyond automated detection of vulnerabilities, you could simulate a real intruder in a controlled, safe manner to confirm vulnerabilities manually. The assessment provides a more structured approach to identifying vulnerabilities that may go undetected. This secondary exploitation may include attempting to exploit trusted relationships between hosts, exploiting password weakness, or gaining administrative access to systems.
• External assessment: The goal of an external assessment is to quantify the security risk that is associated with Internet-connected systems. After researching and confirming the registration of Internet devices, assessors scan the device for external visibility. Because most services have inherent and well-known vulnerabilities, it must be determined whether the services offered are potentially vulnerable.
• Wireless assessment: The wireless assessment provides an evaluation of the security posture of the wireless network within the organization and identifies risks and exposures that are associated with a wireless deployment. Assessors analyze the wireless technology architecture and configurations to identify authorized and unauthorized access points and to recommend solutions to strengthen the security of the wireless infrastructure. Assessors also check outside customer buildings to find wireless network traffic leaking from the buildings.
• Security posture assessment analysis and documentation: This assessment quantifies the security posture of the organization network by using metrics and graphs. The report should also provide technical details, including analysis of each IP address, an explanation of methods that are used to compromise network devices and systems, and a description of the likelihood that an attacker will use that same approach. The report then prioritizes the vulnerabilities, recommends actions to correct the security risks, and details remediation steps that will prevent future exploitation.

Network Security Testing

Security testing provides insight into the other SDLC activities, such as risk analysis and contingency planning. You should document security testing and make the documentation available for staff involved in other IT and security-related areas. Typically, you conduct network security testing during the implementation and operational stages, after the system has been developed, installed, and integrated.

During the implementation stage, you should conduct security testing and evaluation on specific parts of the system and on the entire system as a whole. Security test and evaluation (ST&E) is an examination or analysis of the protective measures that are placed on an information system after it is fully integrated and operational. The following are the objectives of the ST&E:

• Uncover design, implementation, and operational flaws that could allow the violation of the security policy
• Determine the adequacy of security mechanisms, assurances, and other properties to enforce the security policy
• Assess the degree of consistency between the system documentation and its implementation

Once a system is operational, it is important to ascertain its operational status. You can conduct many tests to assess the operational status of the system. The types of tests you use and the frequency in which you conduct them depend on the importance of the system and the resources available for testing. You should repeat these tests periodically and whenever you make a major change to the system. For systems that are exposed to constant threat, such as web servers, or systems that protect critical information, such as firewalls, you should conduct tests more frequently.

Security Testing Techniques

You can use security testing results in the following ways:

• As a reference point for corrective action
• To define mitigation activities to address identified vulnerabilities
• As a benchmark to trace the progress of an organization in meeting security requirements
• To assess the implementation status of system security requirements
• To conduct cost and benefit analysis for improvements to system security
• To enhance other lifecycle activities, such as risk assessments, certification and authorization (C&A), and performance-improvement efforts

There are several different types of security testing. Some testing techniques are predominantly manual, and other tests are highly automated. Regardless of the type of testing, the staff that sets up and conducts the security testing should have significant security and networking knowledge, including significant expertise in the following areas: network security, firewalls, IPSs, operating systems, programming, and networking protocols, such as TCP/IP.

Many testing techniques are available, including the following:

• Network scanning
• Vulnerability scanning
• Password cracking
• Log review
• Integrity checkers
• Virus detection
• War dialing
• War driving (802.11 or wireless LAN testing)
• Penetration testing

Common Testing Tools

Many testing tools are available in the modern marketplace that you can use to test the security of your systems and networks. The following list is a collection of tools that are quite popular; some of the tools are freeware, some are not:

• Nmap
• GFI LanGuard
• Tripwire
• Nessus
• Metasploit
• SuperScan by Foundstone, a division of McAfee

Many other excellent tools exist. This list is only a representative sampling.

Incident Response

Risk cannot be completely eliminated in some business environments.

One way to eliminate risk is to simply withdraw from doing business at all, an unlikely scenario. For this reason, incident response has become an important component of the secure network life cycle. The breadth and sophistication of threat vectors in information security has increased exponentially. Every day new techniques emerge, and the motivation of the attackers becomes increasingly aggressive, driven by political reasons, industrial espionage, and terrorism. Preventative measures help, but not all incidents can be prevented. Risk avoidance is unlikely; risk mitigation is more realistic.

It is, then, almost required to implement an incident response capability to streamline the incident detection capabilities, contain the impact of those incidents to minimize loss and destruction, reduce the scope of weaknesses, and restore services within the parameters of the organization.

Implementing an incident response plan effectively can be challenging because of the amount and scope of the resources needed. The first critical step is to deploy an effective intrusion detection and prevention capability. Even if the incident response plan is not in place, incident detection and prevention can provide a first line of response. However, incident response is not completely effective without framing it within an incident response plan. Assessing the current and potential business impact of incidents is critical. Other crucial factors include the implementation of effective methods of collecting, analyzing, and reporting data. Also, it is important to define the framework of communication between the teams involved (for example, technical teams, human resources, legal) and between the organization and external entities (such as other incident response teams and law enforcement).

Incident Management

The incident response process has several phases:

• Preparation: As with any other activity, preparation is the building block of incident response methodologies. Preparation creates the foundation for a sound incident response plan and lays the groundwork for an incident prevention culture within the organization. These are some examples of the tasks typically implemented during the preparation phase:
  • Prepare the facilities (such as a central coordination room and storage facilities for collected evidence) and the communication mechanisms (cell phones, contact and on-call information, and others).
  • Define the incident analysis hardware and software tools, such as protocol analyzers and forensics software.
  • Define prevention procedures, such as patch management and user awareness and training methods.
• Detection and analysis: With any luck, this is where the incident response team will spend most of its time. This phase starts with the definition of a threat vector classification scheme, in order to define detection and analysis capabilities more effectively per type of threat. Clearly defining the difference between events and incidents is critical. The incident response team should analyze and implement tools for log and event correlation, in order to facilitate the navigation across eventually thousands of security-related events. Efficiently and effectively identifying the business- and risk-relevant incidents out of thousands of events is a key component of the detection strategy. The best way to start is to define a sound framework to prioritize, document, and provide notice about incidents.
• Containment, eradication, and recovery: When an incident has been detected and analyzed, it is important to contain it before the spread of the incident overwhelms resources or the damage increases. The containment strategy could start with a clear definition of tools to identify the attacker through IP addresses, usernames, and other means, followed by a clear definition of the context and time to perform this function (need for evidence preservation, time and resources to implement the strategy, sustainable service availability, and others). All containment strategies should also include steps to eradicate the threat and vulnerabilities, or at least mitigate them, and steps to recover operating systems, hardware components, and productive time. In light of this, ensure that the security policies are adapted to let remediation take place in a timely and effective manner if an attack is detected.
• Post-incident activity: This phase is crucial. The more the incident response team learns from past experience and (specially) mistakes, the more prepared it will be for future incidents. Focusing on how to collect and use data is a good first step. How to document what happened, especially the symptoms and fingerprint of the attack, should follow, leading to a full root-cause analysis. At this point, the incident response team should have a clear understanding of the options to go after the attacker (involve law enforcement, prosecution, and others).

Computer Crime Investigations

If you intend to successfully prosecute an individual who breaches your security, it is necessary to establish three things in most countries (in addition to evidence, the collection of which is covered next):

• Motive: Motive is concerned with why an individual performed the illegal act. As you investigate a computer crime, it is important to start with individuals who might have been motivated to commit the crime.
• Opportunity: Having identified a list of suspects, the next thing to consider is whether they had the opportunity to commit the crime. For example, if you can establish that three of the suspects were all participating in a wedding at the time of the security breach, they may have been motivated, but they did not have the opportunity. They were busy doing something else.
• Means: The means is an important thing to prove as well. Do not accuse someone who does not have the technical knowledge to accomplish the deed. Means is the ability to perform the crime. However, keep in mind that hacking tools have become easy for even a novice to use.

If you do not establish these three things, it is difficult to prove that the perpetrator is guilty of the offense should you decide to prosecute. When you can establish motive, opportunity, and means, and offer evidence, you are closer to a list of possible guilty parties.

When working with computer data as part of a forensics case, you must maintain the integrity of the data if you will rely on the data in a court of law. It is difficult to maintain the integrity of the data in the virtual world of computers where it is trivial to change time stamps or any item of data. The flipping of a single bit can sometimes be all that is required to falsely establish an alibi.

Collection of Evidence and Forensics

Data collection is a volatile thing in the virtual world of computers. For this reason, a common procedure in response to security breaches is the immediate isolation of the infected system. Dumping the memory to disk is required because the system flushes the memory every time a device is powered off. Multiple copies of the hard drive are usually made after the device is powered down, to establish master copies. These master copies are usually locked up in a safe, and investigators use working copies for both the prosecution and the defense. You can answer any charges of tampering with data by comparing working copies to the master copy that has been secured and untouched since the beginning of the investigation.

It is important to note that when making copies of hard drives, a hardware write blocker must be used to ensure that the data on the source drive has not been modified by the copy. EnCase Forensic suite from Guidance Software is a product that uses hardware write blocker.

Laws and Ethics

This section describes key laws and codes of ethics that are binding on information systems security (infosec) professionals.

For many businesses today, one of the biggest considerations for setting security policies is compliance with the law. For that reason, it is important for infosec professionals to be at least conversant in the basics of law.

In most countries, there are three types of laws:

• Criminal: Concerned with crimes, and its penalties usually involve the risk of fines or imprisonment, or both. If fines are paid, they are usually to the court and are used to defray court costs.
• Civil (also called tort): Focuses on correcting wrongs that are not crimes. An example of a civil law case is if one company sues another company for infringing on a patent. The penalty in civil law is usually monetary, although there can also be performance requirements such as ceasing to infringe on the patent. If money is awarded, it is given to the party who won the lawsuit. Imprisonment is not possible in civil law.
• Administrative: Involves government agencies enforcing regulations. For example, a company may owe its employees vacation pay. An administrative court could force the company to pay and would probably also levy a fine that is payable to the agency. Therefore, in administrative law cases, monetary awards are often split between the government agency and the victim whose wrongs have been righted.

Ethics involves a standard that is higher than the law. It is a set of moral principles that adherents follow to be considered ethical. These ethics are often formalized in codes appropriately entitled “codes of ethics” by the professions formalizing the code.

The information security profession has a number of codes that have been formalized:

• International Information Systems Security Certification Consortium, Inc. (ISC)² Code of Ethics
• The Computer Ethics Institute’s Ten Commandments of Computer Ethics
• RFC 1087, “Ethics and the Internet,” by the Internet Activities Board (IAB)
• Generally Accepted System Security Principles (GASSP)

Liability

Companies must take into account the legal liability for the country in which they reside. Take, for example, an Internet service provider (ISP) that has hundreds of e-businesses that rely on the ISP to run their websites with 100 percent uptime. If a hacker or a virus takes down this ISP, there is a chance for the ISP to be found liable, if it is discovered that the ISP did not take enough precautions or did not secure the network against internal or external threats.

In such cases, legal liability is likely to depend on what prevention technologies and practices are available and whether these technologies and practices are reasonably cost-effective to implement. While developing and implementing our security procedures, we must demonstrate due diligence and due care.

Showing due diligence includes everything from implementing technologies such as firewalls, intrusion-detection tools, content filters, traffic analyzers, and VPNs, to having best practices for continuous risk-assessment and vulnerability testing.

Due care is concerned with the operations and maintenance of the secure mechanisms put in place by practicing due diligence.

Lack of due care can lead to downstream liability. This is the case when a network is used by hackers as a springboard to conduct an attack against a third party. The victim of the attack could prosecute not only the hackers, but also the organization whose security was lax enough that its network was used as the launching pad for the attack.

Disaster Recovery and Business Continuity Planning

Business continuity planning and disaster recovery procedures address the continuing operations of an organization in the event of a disaster or prolonged service interruption that affects the mission of the organization. Such plans should address an emergency response phase, a recovery phase, and a return to normal operation phase. You should identify the responsibilities of personnel during an incident and the resources that are available to them.

In reality, contingency and disaster recovery plans do not address every possible scenario or assumption. Rather, they focus on the events most likely to occur and they identify an acceptable method of recovery. Periodically, you should exercise the plans and procedures to ensure that they are effective and well understood.

Business continuity planning provides a short- to medium-term framework to continue the organizational operations. The following are objectives of business continuity planning:

• Moving or relocating critical business components and people to a remote location while the original location is being repaired
• Using different channels of communication to deal with customers, shareholders, and partners until operations return to normal

Disaster recovery is the process of regaining access to the data, hardware, and software necessary to resume critical business operations after a natural or human-induced disaster. A disaster recovery plan should also include plans for coping with the unexpected or sudden loss of key personnel. A disaster recovery plan is part of a larger process known as business continuity planning.

After the events of September 11, 2001, when many companies lost irreplaceable data, the effort put into protecting such data has changed. It is believed that some companies spend up to 25 percent of their IT budget on disaster recovery planning to avoid larger losses. Research indicates that of companies that had a major loss of computerized records, 43 percent never reopened, 51 percent closed within two years, and only 6 percent survived long term (http://searchenterprisewan.techtarget.com/definition/disaster-recovery-plan and http://en.wikipedia.org/wiki/Disaster_recovery).

Not all disruptions to business operations are equal. Whether the disruption is natural or human, intentional or unintentional, the effect is the same. A good disaster recovery plan takes into account the magnitude of the disruption, recognizing that there are differences between catastrophes, disasters, and nondisasters. In each case, a disruption occurs, but the scale of that disruption can dramatically differ.

• Nondisaster: A situation where a business process is unavailable for a given period of time
• Disaster: A situation that makes a facility unusable for an entire day or more
• Catastrophe: A situation that destroys the facility

Business Continuity Concepts

Building a business continuity plan requires extensive planning, with knowledge of the business requirements, budgets, and levels of risk the organization is willing to take. Some of the building block components, however, are more easily defined. The goal, from a rather simplified point of view, is to define objectives for the recovery of host computing systems that run the applications that support the business processes. These objectives are stated as the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

RTO is the number of hours or days that management has set as the objective for resuming a business process or a system. RPO describes the age of the data you want the ability to restore to in event of a disaster. For example, if the RPO is 8 hours, systems should be restored in the state they were in no longer than 8 hours ago. The technical disaster recovery strategy depends upon meeting RTO and RPO specifications. The RTO and RPO requirements determine which option of the disaster recovery plan to implement. Recovery time and how current data is are key components in determining the level of service a business process requires in the event of a major disruption. To properly implement a disaster recovery plan, one must know the RTO and RPO that the organization is willing to accept in a disaster. The technical disaster recovery strategy of different options of recovery is based upon a combination of these requirements.