Chapter 11 Info Security Policy Manager Responsibilities Assignment

User Generated

Obbxtrrx

Computer Science

Description

Perform exercise 3 and 4 in chapter 11. Create a list of what you consider the top 5 tools, include the info for exercise 4 plus the cost.

Consider using a table to make it easy to ready.

Exercise 3: This chapter lists five tools that can be used by security administrators, network administrators, and attackers alike. Search the Web for three to five other tools that fit this description.

Exercise 4: Using a Web browser and the names of the tools you found in Exercise 3, find a site that claims to be dedicated to supporting hackers. Do you find any references to other hacker tools? If you do, create a list of the tools along with a short description of what they do and how they work.

Please find the attached Text book (chapter 11).

Unformatted Attachment Preview

11 CHAPTER SECURITY MAINTENANCE We want a fresh start only because we didn't sufficiently care for the last fresh start. -CRAIG D. LOUNSBROUGH Upon completion of this material, you should be able to: Discuss the need for ongoing maintenance of the information security program Define a model for a full maintenance program Identify the key factors involved in monitoring the external and internal environment Describe how planning, risk assessment, vulnerability assessment, and remediation tie into information security maintenance Explain how to build readiness and review procedures into information security maintenance Iris leaned back in her chair. It was Monday morning. the first workday after the biggest conversion weekend in the implementation of the Random Widget Works information security upgrade project Iris had just reviewed the results. So far, everything had gone according to plan. The initial penetration tests run on Sunday afternoon were clean, and every change request processed over the past three months had gone through without any issues. Iris was eager to return to the routine she had begun to enjoy since her promotion to CISO. Kelvin Urich, the lead security ana lyst, tapped on the open door of Iris' office. "Hey, Iris," he said, "Have you seen the e-mail I just sent? There's an urgent vulnerability report on Bugtraq about the version of Apache we use. Something called the OptionsBleed bug. The open-source community just released a critica l patch and they recommend it be applied right away. Should I get the system programming team started on it?" 567 ' CHAPTER 11 Secur ity Ma intenance "Absolutely! Get them to pull the download from the distribution site as soon as they can," said Iris. "But remember we need to follow our maintenance plan and each of the quality assurance steps carefully. Before they install it on a s ingle production system, I want you to review the test results and QA report yourself. After you sign off on the test results, have them patch the servers for the HQ development team. Oh, and don't forget you need to get change orders into change control ASAP if we go forward on the patch and you plan to hit tonight's critical systems change window." ''I'll get right on it," Kelvin said. After Kelvin left, Iris pulled up Bugtraq on her PC. She was reading about the new vulnerability when she heard another knock on the door. It was Linda Simpson, the new compliance team lead. "Hi, Iris," Linda said. "Got a second?" "Sure, Linda. How have you been? Settling in okay?" She sm iled and nodded. "Yeah, this is a good group. Everyone pitched in and helped round up the documentation I needed. I am studying the documentation trai l from the time before the security program was implemented. I came to see you about the reassessment of the information asset inventory and the threat-vu lnerability update that you asked for." Iris was confused for a second, but then she remembered the task she had assigned to Linda. "Oh, right," she sa id, with a slight grimace. "Sorry-I had put the quarterly asset and threat review out of my mind wh ile we were busy implementing the program. I suppose it's time to start planning for the regular reviews, isn't it?" Linda handed her a folder and sa id, "Here's the first draft of the plan for the review project. Maria and Kelvin have already seen it, and they suggested I review it with you. Cou ld you take a look and let me know when you would like to go over it in deta il?" Introduction to Security Maintenance After successfully implementing and testing a new and improved information security profile, an organization may feel more confident about th e level of protection it provides for its information assets. But it shouldn't, really. In all likelihood, a good deal of time has passed since the organization began implementing changes to the information security program. In that time, the dynamic aspects of th e organization's environment will h ave changed. Almost all aspects of a company's environment are dynamic, meaning threats that were originally assessed in the early stages of the organization's risk management program have probably changed and new priorities have emerged. New types of attacks such as viruses, worms, and denialof-service attacks have been developed, and new variants of existing attacks h ave probably emerged as well. In addition, a h ost of other variables outside and inside the organization have most likely changed. CHAPTER 11 Security Ma inte n ance ' Developing a comprehensive list of dynamic factors in an organization's environment is beyond the scope of this text. However, the following changes may affect an organization's information security environment: The acquisition of new assets and the divestiture of old assets The emergence of vulnerabilities associated with new or existing assets Shifting business priorities The formation of new partnerships The dissolution of old partnerships The departure of personnel who are trained, educated, and aware of policies, procedures, and technologies • The hiring of new personnel As this list shows, by the time a cycle of the risk management program is completed, the environment of an organization has probably changed considerably. An information security team needs to be able to assure management periodically that the information security program is accommodating these changes. If the program is not adjusting adequately to change, it may be necessary to begin the cycle again. If an organization deals successfully with change and has created procedures and systems that can be adjusted to the environment, the existing security improvement program can continue to work well. Deciding whether to continue with the current improvement program or to renew the investigation, analysis, and design phases depends on how much change has occurred and how well the organization and its program for information security maintenance is adapting to its evolving environment. Before learning about the maintenance model that the authors recommend, you need some background on the management and operation of an information security program. In this chapter, you will learn about the methods organizations use to monitor the three primary aspects of information security risk management, which are sometimes called the security triple: threats, assets, and vulnerabilities. • • • • • • Security Management Maintenance Models To manage and operate the ongoing security program, the information security community must adopt a management maintenance model. In general, management models are frameworks that structure the tasks of managing a particular set of activities or business functions. NIST SP 800-100, Information Security Handbook: AGuide for Managers Key Terms auditing The review of a system's use to determine if misuse or malfeasance has occurred. build Asnapshot of a particular version of software assembled or linked from its component modules. 569 CHAPTER 11 Secur ity Ma intenance build list A list of the versions of components that make up a build. configuration A collection of components that make up a configuration item. configuration and change management (CCM) An approach to implementing system change that uses policies, procedures, techniques, and tools to manage and evaluate proposed changes, track changes through completion, and maintain systems inventory and supporting documentation. configuration item A hardware or software item that will be modified and revised throughout its life cycle. configuration management (CM) See configuration and change management (CCM). major release A significant revision of a version from its previous state. minor release (update or patch) A minor revision of a version from its previous state. revision date The date associated with a particular version or build. software library A collection of configuration items that is usually controlled and that developers use to construct revisions and issue new configuration items. version The recorded state of a particular revision of a software or hardware configuration item. The version nu mber is often noted in a specific format, such as "M.N.b." In this notation, "M" is the major release number and "N.b" can represent va rious minor releases or builds within the major release. NIST Special Publication (SP) 800 - 100, Information Security Handbook: A Guide for Managers, provides managerial guidance for the establishment and implementation of an information security program. In particular, the handbook addresses the ongoing tasks expected of an information security manager once the program is working and day-to-day operations are established. For each of the 13 areas of information security management presented in SP 800 - 100, there are specific monitoring activities- tasks that security managers should perform on an ongoing basis to monitor the function of the security program and take corrective actions when issues arise. Not all issues are negative, as in the opening scenario. Some are normal changes in the business environment, while others are changes in the technology environment-for example, the emergence of new technologies that could improve security or new security standards and regulations to which the organization should subscribe. The following sections describe monitoring actions for the 13 information security areas. These sections were adapted from SP 800 - 100. Note@ For mo re information on NIST SP 800-100 and other NIST special publications, visit csrc.nist.govlpub/ications/PubsSPs.html. I CHAPTER 11 Security Ma in te n ance 571 ' 1. Information Security Governance As described in Chapters 1 and 3, an effective information security governance program requires constant review. Agencies should monitor the status of their programs to ensure that: • Ongoing information security activities are providing appropriate support to the agency's mission. • Policies and procedures are current and aligned with evolving technologies, if appropriate. • Controls are accomplishing their intended purpose. Over time, policies and procedures may become inadequate because of changes in the agency's mission and operational requirements, threats, or the environment; deterioration in the degree of compliance; or changes in technology, infrastructure, or business processes. Periodic assessments and reports on activities can identify areas of noncompliance, remind users of their responsibilities, and demonstrate management's commitment to the security program. While an organization's mission does not frequently change, the agency may expand its mission to secure its programs and assets and require modification to its information security requirements and practices. Table 11- 1 provides a broad overview of key ongoing activities that can assist in monitoring and improving an agency's information governance activities. Table 11-1 Ongoing Monitoring Activities of Information Security Governance' Activities Plans of Action and Milestones (POA&Ms) Measu rement and Metrics Description of Activities POA&Ms assist in identifying, assessing, prioritizing, and monito ring the progress of corrective efforts for secu rity weaknesses found in programs and systems. The POA&M tracks the measures implemented to correct deficiencies and to reduce or eliminate known vu lnerabilities. POA&Ms can also assist in identifying performance gaps, evaluating an agency's security performance and efficiency, and conducting oversight. Metri cs are tools designed to improve performance and accountability through the collection, analysis, and reporting (measurement) of relevant performance data. Information secu rity metrics monitor the accomplishment of goals and objectives by quantifying the implementation level of security controls and their efficiency and effectiveness, by analyzing the adequacy of secu rity activities, and by identifying possible improvements. The terms metric and measurement seem to have some overlap in their meanings. A metric is usua lly meant to be a mo re abstract, highe r-level, or subjective value, while measures tend to be mo re objective and concrete. (continues) CHAPTER 11 I Table 11-1 Secur ity Ma in tena n ce Ongoi ng Monito ring Activities of Informat ion Security Governance' (continued) Activities Description of Activities Continuous Assessment (CA) The CA process monitors the initial security accreditation of an information system to track changes to it, ana lyzes the security impact of those changes, makes appropriate adjustments to the security controls and the system's secu rity plan, and reports the system's secu rity status to appropriate agency officials. CM is an essential component of monitoring the status of security controls and identifying potential security problems in information systems. This information can help security managers understand and monitor the evolving natu re of vu lnerabilities that appea r in a system under their responsibil ity, thus enabling managers to direct app ropriate changes as required. Information about network performance and user behavior on the network helps security program managers identify areas in need of improvement and point out potential performance improvements. This information can be correlated with other sources of information, such as the POA&M and CM, to create a comprehensive picture of the security program. Incide nt statistics are valuable in determining the effectiveness of implemented security policies and procedures. Incident statistics provide security program managers with fu rther insights into the status of secu rity programs under thei r purview, help them observe performance trends in program activities, and inform them about the need to change policies and procedures. Configuration Management (CM) Network Monito ring Incident and Event Statistics Source: NIST SP 800· 100. 2. Systems Development Life Cycle As you learned in Chapter 3, the systems development life cycle (SDLC) is the overall process of developing, implementing, and retiring information systems through a multistep approach- initiation, analysis, design, implem entation, and maintenance to disposal. Each phase of the SDLC includes a minimum set of information security activities required to effectively incorporate security into a system. SP 800- 64 Rev. 2, Security Considerations in the Information System Development Life Cycle, presents a framework for incorporating security into all phases of the SDLC to ensure the selection, acquisition, and use of appropriate and cost-effective security controls. During this phase, the organization should continuously monitor system performance to ensure that it is consistent with established user and security requirements and that needed system modifications are incorporated. For configuration and change management (CCM ), also known as configuration management (CM ), it is important to document proposed or actual changes in the system security plan. Information systems are typically in a constant state of evolution CHAPTER 11 Security Ma inte nance with upgrades to hardware, software, and firmware and possible modifications to the system's surrounding environment. Documenting information system changes and assessing their potential impact on system security is an essential part of continuous monitoring and key to avoiding a lapse in system security accreditation. Monitoring security controls helps to identify potential security problems in the information system that are not identified during the security impact analysis. This analysis is conducted as part of the CM and control process. 3. Awareness and Training As you learned in Chapter 5, once the program has been implemented, processes must be put in place to monitor compliance and effectiveness. An automated tracking system should be designed to capture key information about program activity, such as courses, dates, audience, costs, and sources. The tracking system should capture this data at an agency level so it can be used to provide enterprise-wide analysis and reporting about awareness, training, and education initiatives. Tracking compliance involves assessing the status of the program as indicated by the database information and mapping it to standards established by the agency. Reports can be generated and used to identify gaps or problems. Corrective action and necessary follow-up can then be taken. This follow-up may take the form of formal reminders to management; additional awareness, training, or education offerings; and th e establishment of a corrective plan with scheduled completion dates. As the organization's environment changes, the security policies must evolve, and all awareness and training material should reflect these changes. 4. Capital Planning and Investment Control Increased competition for limited resources requires that departments allocate available funding toward their highest-priority information security investments to afford the organization the appropriate degree of security for its needs. This goal can be achieved through a formal enterprise capital planning and investment control (CPIC) process designed to facilitate the expenditure of agency funds. NIST SP 800- 65, Integrating IT Security into the Capital Planning and Investment Control Process, provides a seven-step process for prioritizing security activities and corrective actions for funding purposes: Identify the baseline: Use information security measurements or other available data to baseline th e current security posture. 2. Identify prioritization requirements: Evaluate the security posture against legislative requirements, other requirements from the chief information officer (CIO), and the agency's mission. 3. Conduct enterprise-level prioritization: Prioritize potential information security investments at the enterprise level against the agency's mission and prioritize the financial impact of implementing appropriate security controls. 4. Conduct system-level prioritization: Prioritize potential system-level corrective actions against the system category and corrective action impact. 1. CHAPTER 11 Secur ity Ma intenance 5. Develop supporting materials: For enterprise-level investments, develop an initial conceptual business plan, business case analysis, and Exhibit 300. For system-level investments, adjust Exhibit 300 to request additional funding that mitigates prioritized weaknesses. 6. Implement an investment review board {!RB) and portfolio management: Prioritize agency-wide business cases against requirements and CIO priorities and determine the investment portfolio. 7. Submit any required budget approval paperwork.' 5. Interconnecting Systems A system interconnection is defined as the direct connection of two or more information systems for sharing data and other information resources. Organizations choose to interconnect their information systems for a variety of reasons based on their needs. For example, they may interconnect information systems to exchange data, collaborate on joint projects, or securely store data and backup files. Interconnecting information systems can expose the participating organizations to risk. For instance, if the interconnection is not properly designed, security failures could compromise the connected systems and their data. Similarly, if one of the connected systems is compromised, the interconnection could be used as a conduit to compromise the other system and its data. NIST SP 800-47 details a four-phase life cycle management approach for interconnecting information systems that emphasizes information security: • Phase 1: Planning the interconnection • Phase 2: Establishing the interconnection • Phase 3: Maintaining the interconnection • Phase 4: Disconnecting the interconnection 6. Performance Measurement As described in Chapter 9, a program of performance measurement provides numerous financial and administrative benefits to organizations. Organizations can develop information security metrics that measure the effectiveness of their security program, and can provide data to be analyzed and used by program managers and system owners to isolate problems, justify investment requests, and target funds to the areas in need of improvement. By using specific measurements to target security investments, agencies can get the best value from available resources. The typical information performance management program consists of four interdependent components: senior management support, security policies and procedures, quantifiable performance measures, and analyses. Information security measurements should be used for monitoring the performance of information security controls and initiating performance improvements. In reality, a process like this does not often proceed in such a direct fashion; instead, give and take is common as control objectives are balanced against the availability of resources. I CHAPTER 11 Security Ma in te n ance ' Control Performance Baselines and Measurements Because many technical controls for information security are implemented on common IT processors, th ey are affected by the same factors as most computerbased technologies. Therefore, it is important to monitor the performance of security systems and their underlying IT infrastructure to determine if they are working effectively. This type of performance monitoring is especially important for network appliances such as firewalls and content filters that look for inappropriate use of Internet resources and operate as pass-by devices. When these types of appliances are not sized correctly or are not properly tuned for sufficient performance, they do not stop the actions they are designed to block. Some common system and network measurements used in performance management are also applicable in security, especially when th e components being managed involve th e ebb and flow of network traffic. The following list- based on what is known as the 60 percentage rule- offers a few guidelines that security personnel can use when exploring th e issues of system and network performance. • When the memory usage associated with a particular CPU-based system averages or exceeds 60 percent over prolonged periods, consider adding more memory. • When the CPU usage associated with a particular CPU-based system averages or exceeds 60 percent over prolonged periods, consider an upgrade for the CPU or an increase in the number of CPUs dedicated to the function. • When the network traffic on a particular link averages or exceeds 60 percent over prolonged periods, consider an upgrade to the link, which can be accomplished either by increasing the available bandwidth or segmenting the traffic. • When the amount of data stored on a particular hard drive exceeds 60 percent of available capacity over a prolonged period, consider an upgrade, which can be accomplished either by replacing the hard drive with a larger-capacity drive or adding more drives. To evaluate the performance of a security system, administrators must establish system performance baselines, as described in Chapter 9. Organizations should establish baselines for different criteria and for various periods of time, such as days of the week, weeks of the year, months of the year, and times of day, among others. For example, network traffic levels are deemed to be high when traffic reaches or surpasses the level of the performance baseline. To put it another way, the planning of capacity upgrades should begin before users complain about issues such as slow-loading Web pages. 7. Security Planning Planning for information security was discussed in detail in Chapter 3. Planning is one of the most crucial ongoing responsibilities in security management. Strategic, tactical, and operating plans must be developed that align with and support organizational and IT plans, goals, and objectives. 575 CHAPTER 11 Secur ity Ma in tena n ce This section of SP 800- 100 focuses on the controls available to address shortfalls identified in the planning process. A Federal Information Processing Standard (FIPS) named FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, specifies federal security requirements in 17 areas. In addition to reviewing the minimum security requirements in FIPS 200, private organizations would benefit from studying the controls in SP 800- 53, Recommended Security Controls for Federal Information Systems. NIST SP 800 - 18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems, provides a template for a systems security plan in Appendix A of the document. 8. Information Technology Contingency Planning Contingency planning, covered in Chapter 10, consists of a process for recovery and documentation of procedures for conducting recovery. The ongoing responsibilities of security management involve the maintenance of the contingency plan. The contingency plan must always be in a ready state for use immediately upon notification. Periodic reviews of the plan must be conducted to ensure currency of key personnel and vendor information, system components and dependencies, the recovery strategy, vital records, and operating requirements. While some changes may be obvious, such as personnel turnover or vendor changes, others require analysis. The business impact analysis should be reviewed periodically and updated with new information to identify new contingency requirements and priorities. Changes to the plan are noted in a record of changes, dated, and signed or initialed by the person making the change. The revised plan or plan sections are circulated to those with plan responsibilities. Because of the impact that plan changes may have on interdependent business processes or information systems, the changes must be clearly communicated and properly annotated at the beginning of the document. 9. Risk Management Risk management, covered in Chapters 6 and 7, is an ongoing effort as well. Risk identification, analysis, and management are a cyclic and fundamental part of continuous improvement in information security. The principal goal of risk management is to protect the organization and its ability to perform its mission, not just protect its information assets. Risk management is an essential management function of the organization that is tightly woven into the SDLC. Because risk cannot be eliminated entirely, the risk management process allows information security program managers to balance operating and economic costs of protective measures and achieve gains in mission capability. By employing practices and procedures designed to foster informed decision making, agencies help protect their information systems and the data that support their own mission. Many risk management activities are conducted during a snapshot in time- a static representation of a dynamic environment. All the changes that occur to systems during normal, daily operations have the potential to adversely affect system security in some fashion. The goal of the evaluation and assessment process in risk management CHAPTER 11 Security Ma inte nance ' is to ensure that the system continues to operate safely and securely. This goal can be partially reached by implementing a strong configuration management program. In addition to monitoring the security of an information system on a continuous basis, agencies must track findings from the security control assessment to ensure they are addressed appropriately and do not pose risks to the system or introduce new ones. The process of managing risk permeates the SDLC, from the early stages of project inception through the retirement of the system and its data. From inception forward, agencies should consider possible threats, vulnerabilities, and risks to the system so they can better prepare it to operate securely and effectively in its intended environment. During the security certification and accreditation process, a senior agency official determines whether the system is operating within an acceptable risk threshold. 10. Certification, Accreditation, and Security Assessments Certification and accreditation for federal systems is radically changing for systems not designated as national security information systems. Some organizations need to review their own systems for certification and accreditation to be in compliance with banking, healthcare, international, or other regulations. Others may want the recognition offered by certifications like the ISO 27000 series. The security certification and accreditation process is designed to ensure that an information system operates with the appropriate management review, that there is ongoing monitoring of security controls, and that reaccreditation occurs periodically. The continuous monitoring of a security assessment program, as a function of certification and accreditation, is an essential component of any security program. During this phase, the status of security controls in the information system is checked on an ongoing basis. An effective continuous monitoring program can be used to support the annual requirement specified in the Federal Information Security Management Act (FISMA) for assessing security controls in information systems. At a minimum, an effective monitoring program requires the following: • Configuration management and configuration control processes for the information system • Security impact analyses on changes to the information system • Assessment of selected security controls in the information system and reporting of the system's security status to appropriate agency officials To determine which security controls to select for review, agencies should first prioritize testing on "plan of action" items and milestone items that become closed. These newly implemented controls should be validated. Organizations should test against system-related security control changes that did not constitute a major change or require new certification and accreditation. Organizations should identify all security controls that are continuously monitored as annual testing and evaluation activities. Once this is complete, organizations should look at remaining controls 577 CHAPTER 11 Secur ity Ma in tena n ce that have not been tested that year and make a decision about further annual testing based on risk, the importance of the control, and the date of the last test. The results of continuous monitoring should be reviewed regularly by senior management and any necessary updates should be made to the system security plan. An example form for continuously monitoring reporting is provided in NIST SP 800-53A. Part of the ongoing security assessment is auditing. Most computer-based systems used in information security can create logs of their activity. These logs are a vital part of the detective functions associated with determining what happened, when it happened, and how. Managing systems logs in large organizations is a complex process and is sometimes considered an art in itself. Unless security or systems administrators are vigilant, the logs can pile up quickly because systems are constantly writing the activity that occurs on them. Fortunately, automated tools known as log analyzers can consolidate systems logs, perform comparative analysis, and detect common occurrences or behavior of interest . Behavior of interest may include port scanning and other anomalous network activity, malware signatures, hacking attempts, and illicit use of controlled network resources or computer systems. Log analyzers, a component of some intrusion detection and prevention systems (IDPSs), can detect activities in real time. Each type of IDPS, whether host-, network-, or application-based, also creates logs. These logs are invaluable records of events and should be archived and stored for future review as needed. System intruders have been known to attempt to cover their tracks by erasing entries in logs, so wise administrators configure their systems to create duplicate copies of the logs and store the copies on sources that cannot be easily modified, like optical disk technologies such as CD-Rand DVD-R. Many vendors offer log consolidation and analysis features that allow for integration of log files from multiple products, such as firewalls, network equipment, and even products from other vendors. To assist organizations in meeting their reporting requirements, NIST SP 800-100 provides an information security assessment survey that covers many of the areas typically required for inclusion in reports. The questionnaire can be customized for an organization or program and can be completed by the CIO, the CISO, or an independent assessor of the agency's information security program. 11. Security Services and Products Acquisition Information security services and products are essential elements of an organization's information security program. Such products are widely available in the marketplace and are frequently used by federal agencies. Security products and services should be selected and used to support the organization's overall program to manage the design, development, and maintenance of its information security infrastructure and to protect its mission-critical information. Agencies should apply risk management prin ciples to help identify and mitigate risks associated with product acquisition. When acquiring information security products, organizations are encouraged to conduct a cost-benefit analysis- one that also includes the costs associated with risk CHAPTER 11 Security Ma in te n ance mitigation. This analysis should include a life cycle cost estimate for current products and one for each identified alternative while highlighting the benefits associated with each alternative. NIST SP 800-36, Guide to Selecting Information Technology Security Products, defines broad security product categories and then specifies product types, product characteristics, and environment considerations within those categories. The guide also provides a list of pertinent questions that agencies should ask when selecting products. The process of selecting information security products and services involves numerous people throughout an organization. Each person or group involved in the process should understand the importance of security in the organization's information infrastructure and the security impacts of their decisions. Personnel might be included from across the organization to provide relevant perspective on information security needs that must be integrated into the solution. Just as the SDLC supports the development of products, the security services life cycle (SSLC) provides a framework to help decision makers organize and coordinate their security efforts from initiation to completion. Figure 11- 1 depicts the SSLC for obtaining security services at a high level. Table 11- 2. provides a brief summary of each phase. Initiation Phase Determining the need Assessment Phase Identifying viable solutions Operations Phase Ensuring operational Solution Phase Specifying the right solution success Implementation Phase Engaging the right source '-- -=-~--••• Closeout Phase Ensuring successful closure Figure 11-1 The information security services life cycle Source: NISr SP 800·35. 3 - - -- CHAPTER 11 Secur ity Ma in tena n ce ~ The Information Security Services Life Cycle• Phase Activity Phase 1- lnit iation • Begins when t he need to initiate the services life cycle is recogn ized • Consist s of needs det ermination, secu rity cat egorization, and the preliminary r isk assessment Phase 2- Assessment • Involves developing an accurate portrait of t he cu rrent environment before identifying possible so lut ions f or consideration by decision makers • Baselines t he existing environment; met rics creat ion, gathering, and analysis; and t ota l cost of ownership • Analyzes opportunities and barriers • Ident ifies options and r isks Phase 3- Solution • Appropriate solut ion from t he viable opt ions ident ified dur ing the selected assessment phase • Develops the business case • Develops the service arrangement • Develops the imp lementation plan Phase 4Implementat ion • Service p roviders are implemented during t his phase • Ident ifies the service p rovider and develops the service agreement • Finalizes and executes t he implementat ion plan • Manages expect ations Phase 5-0perations • The service's life cycle becomes iterat ive; t he service is working, the service p rovided is f ully installed, and a constant assessment must be made of t he service level and source performance • Monitors and measures organizat ion performance • Evaluates cur rent operations and directs actions for continuous improvement Phase 6- Closeout • Because of the iterative nature of t he life cycl e, the service and service provider cou ld continue indefinitely, but this is unlikely • If the environment changes, information security program managers w ill identify t riggers t hat initiate new and replacement services for infor mat ion security • Select s the approp riate exit st rategy • Implements the se lected exit st rategy Source: NIST SP 800-36, Guide to Selecting Information Technology Security Products. CHAPTER 11 Security Ma in te n ance Vulnerabilities in IT products surface nearly every day, and many ready-to -use exploits are available on the Internet. Because IT products are often intended for a wide variety of audiences, restrictive security controls are usually not enabled by default, so many IT products are immediately vulnerable out of th e box. Security program managers should review NIST SP 800- 70, Rev. 3, National Checklist Program for IT Products: Guidelines for Checklist Users and Developers, which helps them develop and disseminate security checklists so that organizations and individual users can better secure their IT products. In its simplest form, a security configuration checklist is a series of instructions for configuring a product to a particular operating environment. This checklist is sometimes called a lockdown or hardening guide or benchmark. 12. Incident Response As illustrated throughout this text, attacks on information systems and networks have become more numerous, sophisticated, and severe in recent years. While preventing such attacks would be the ideal course of action, not all security incidents can be prevented. Every organization that depends on information systems and networks should identify and assess the risks to its systems and reduce those risks to an acceptable level. An important component of this risk management process is the trending analysis of past computer security incidents and the identification of effective ways to deal with them. A well-defined incident response capability helps the organization detect incidents rapidly, minimize loss and destruction, identify weaknesses, and restore IT operations rapidly. Help desk personnel must be trained to distinguish a security problem from other system problems. As help desk personnel screen problems, they must also track the activities involved in resolving each complaint in a help desk information system. The tracking process is commonly implemented using a trouble ticket. A trouble ticket is opened when a user calls about an issue and is closed when help desk or technical support personnel resolve the issue. One key advantage to having formal help desk software is the ability to create and develop a knowledge base of common problems and solutions. This knowledge base can be searched when a user problem comes up; ifit is similar to a problem that was already reported and resolved, complaints can be resolved more quickly. This knowledge base can also generate statistics about th e frequency of problems by type, by user, or by application, and thus can detect trends and patterns in the data. Incidentally, some user problems may actually be created or influenced by a security program because modifications to firewalls, implementations of !DPS rules, or new systems policies in the network can directly affect how users interact with the systems. A significant number of help desk trouble tickets are the result of user access issues involving passwords and other mechanisms of authentication, authorization, and accountability. Proper user training and ongoing awareness campaigns can reduce these problems but not completely eliminate them. CHAPTER 11 Secur ity Ma intenance The Help Desk With a relatively small investment in an IT help desk, an organizatio n can improve th e quality of its IT support and information security function. A small help desk w ith only a few call agents can provide service for an organization of several hundred users. Large organ izations can also improve customer service through the use of a help desk, as long as it receives adequate funding and effective management. Although it may function differently depending on the organization, a help desk common ly provides the following services: • A single po int of contact for service requests from users • Initial screen ing of requests, answering common questions, so lving common problems, and dispatching other types of calls to other units • Entering all calls into a tracking system • Dispatching service providers to respond to ca lls • Report ing and analysis of call volumes, patterns, and process improvement • Early detection of adverse events, which could escalate to incidents or foreshadow disasters Other services that may be integrat ed into the help desk include the following: • Desk-side support for common IT applications such as Windows, end-user computing tools, and common applica tions • Managing new users • Timely removal of users who no longer need system access • Password management • Smart card management • Knowledge management for service requests and optimum resolutions • Server configuration • Network monitoring • Server capacity monitoring • Virus activity monitoring and virus pattern management While each organization has its own approach to creating and developing a help desk solution, many help desks evolve and alter th eir mix of services over time.' To resolve a probl em, a support technician m ay need to visit a user's office to examine equipment or observe the user's procedures, or interact with other departments or workgroups. Th e h el p desk team som etimes includes a dedicated security technician. In any case, the person working to resolve the trouble ticket must document both the di agnosi s and the resol ution, as they are i nvaluabl e components of the knowledge base. Once the probl em has been resolved and the results are documented, the ticket i s closed. CHAPTER 11 Secu rity Ma intenance ' 13. Configuration and Change Management The purpose of configuration and change management is to manage the effects of changes or differences in configurations in an information system or network. In some organizations, configuration management is the identification, inventory, and documentation of the current information systems- hardware, software, and networking configurations. Change management is sometimes described as a separate function that only addresses modifications to this base configuration. Here, the two concepts are combined to address the current and proposed states of the information systems and the management of any needed modifications. Note@ To see an example framework for software product line practice- a best practice configuration management approach- visit the Software Engineering lnstitute's Web site at www.sei.cmu.edu!productlineslframe_report/config.man.htm. Just as documents should have version numbers, revision dates, and other features designated to monitor and administer changes made to them, so too should the technical components of systems, such as software, hardware, and firmware. Several key terms are used in the management of configuration and change in technical components, as shown in the following hypothetical example. Let's assume that XYZ Security Solutions Corporation has developed a new software application called Panacea, the Ultimate Security Solution. Panacea is the configuration item. Panacea's configuration consists of three major software components: See-all, Know-all, and Cure-all. Thus, Panacea is version 1.0, and it is built from its three components. The build list is See-all 1.0, Know-all 1.0, and Cure-all 1.0, as this is the first major release of the complete application and its components. The revision date is the date associated with the first build. To create Panacea, the programmers at XYZ Security Solutions pulled information from their software library. Suppose that while the application is being used in the field, the programmers discover a minor flaw in a subroutine. When they correct this flaw, they issue a minor release, Panacea 1.1. If at some point they need to make a major revision to the software to meet changing market needs or fix more substantial problems with the subcomponents, they would issue a major release, Panacea 2 .0. In addition to the challenge of keeping applications at the current version level, administrators face the release of newer versions of operating systems and ongoing rollouts of newer hardware versions. The combination of updated hardware, operating systems, and applications is further complicated by the constant need for bug fixes and security updates to these elements. CCM assists in streamlining change management processes and prevents changes that could adversely affect the security posture of a system. In its entirety, the CCM 583 CHAPTER 11 Secur ity Ma in tena n ce process reduces the risk that any changes to a system will compromise the system or data's confidentiality, integrity, or availability, because the process provides a repeatable mechanism for effecting system modifications in a controlled environment. In accordance with the CCM process, system changes must be tested prior to implementation to observe the effects of the change and m inimize the risk of adverse results. NIST SP 800- 64, Rev. 2, Security Considerations in the System Development Life Cycle, states: Configuration management and control procedures are critical to establishing an initial baseline of hardware, software, and firmware components for the information system and subsequently to controlling and maintaining an accurate inventory of any changes to the system. Changes to the hardware, software, or firmware of a system can have a significant impact on the security of the system ... changes should be documented, and their potential impact on security should be assessed regularly.• NIST SP 80 0 - 53, Rev. 4, Security and Privacy Controls for Federal Information Systems and Organizations, defines seven CM controls that organizations are required to implement based on an information system's security categorization. The required CM controls are defined in Table 11-3. NIST SP 800-53, Rev. 4, Configuration Management Control Family7 Identifier Title CM-1 Configuration Management Policy and Procedures CM-2 Baseline Configuration CM-3 Configuration Change Control Control The organization: a. Develops, documents, and d isseminates a CM policy that addresses purpose, scope, roles, responsib ilities, management commitment, coord ination among organizational entities, and compliance; and develops, documents, and disseminates procedures to facilitate the im plementation of the CM policy and associated CM controls b. Reviews and updates the cu rrent CM policy and CM procedures Under configuration control, the organization develops, documents, and mainta ins a current baseline configuration of the information system. The organization: a. Determines the types of changes to the information system that are configuration-controlled b. Reviews proposed configuration-contro lled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses CHAPTER 11 Security Ma intenance ' 585 NIST SP 800-53, Rev. 4, Configuration Management Control Family7 (continued) Identifi er Title Control c. Document s configu ration change decisions associated w ith the information system d. Implements approved configuration -controlled changes t o the information system e. Ret ains records of configuration-controlled changes t o the information system f or a specified t ime period f. Aud it s and reviews activities associat ed with configuration controlled changes to the informat ion syst em g. Coordinat es and provides oversight f or configuration change control act ivities through the organization's configuration change cont rol committ ee or board CM -4 Security Im pact Ana lysis The organizat ion analyzes changes to t he inf ormat ion syst em to det ermine potential security impacts prior to change implement ation. CM -5 Access Rest rictions for Change The organizat ion defines, document s, approves, and enforces physical and logical access restrictions associat ed with changes to the information system. CM -6 Configuration Sett ings The organizat ion establishes and documents configuration settings for information technology products employed within the information system, using security configuration checklists that reflect t he most restrict ive mode consistent w ith operating requirements; implements the configuration sett ings; identifies, documents, and approves any deviat ions from established configu rat ion settings for the organ ization's information system components based on operat ing requirements; and monitors and controls changes to t he configuration settings in accordance w ith t he organization's policies and procedu res. CM -7 Least Functionality The organizat ion configu res t he information system t o provide only essent ial capabilities, and prohibits or restricts t he use of ce rtain funct ions, ports, protocols, and services. Source: NISTSP 800·53, Rev. 4. The CM process identifies the steps required to ensure that all ch anges are properly requested, evaluated, and authorized. The CM process also provides a detailed, stepby-step procedure for identifying, processing, tracking, and documenting changes. An exampl e CM process is described in the following sections. Step 1: Identify Change The first step of the CM process begins when a person or process associ ated with the information system identifies the need for a change. Th e change can be initiated by CHAPTER 11 Secur ity Ma intena nce numerous people, such as users or system owners, or it may be identified by audit findings or other reviews. A change may consist of updating the fields or records of a database or upgrading the operating system with the latest security patches. Once the need for a change has been identified, a change request should be submitted to the appropriate decision-making body. Step 2: Evaluate Change Request After initiating a change request, the organization must evaluate possible effects that the change may have on the system or other interrelated systems. An impact analysis of the change should be conducted using the following guidelines: • Whether the change is viable and improves the performance or security of the system • Whether the change is technically correct, necessary, and feasible within the system constraints • Whether system security will be affected by the change • Whether associated costs for implementing the change were considered • Whether security components are affected by the change Step 3: Implementati on Decision Once the change has been evaluated and tested, one of the following actions should be taken: • Approve: Implementation is authorized and may occur at any time after the appropriate authorization signature has been documented. • Deny: The request is immediately denied regardless of circumstances and the information provided. • Defer: The immediate decision is postponed until further notice. In this situation, additional testing or analysis may be needed before a final decision can be made. Step 4: Implement Approved Change Request Once the decision has been made to implement the change, it should be moved from the test environment into production. If required, the personnel who update the production environment are not the same people who developed the change. This requirement provides greater assurance that unapproved changes are not implemented into production. Step 5: Continuous Monitoring The CCM process calls for continuous system monitoring to ensure that it is operating as intended and that implemented changes do not adversely affect the system's performance or security posture. Agencies can achieve the goals of continuous system monitoring by performing configuration verification tests to ensure that the selected configuration for a given system has not been altered outside the established CCM process. In addition to configuration verification tests, agencies can also perform system audits. Both require an examination of system characteristics and supporting documentation to verify that the configuration meets user needs and ensure that the current configuration is the approved system configuration baseline. CHAPTER 11 Security Ma inte nance ' As part of the overall CCM process, agencies should also perform patch management during this step. Patch management helps lower the potential risk to a network by "patching" or repairing known vulnerabilities in any of the network or system environments. Increasingly, vendors are proactive in developing fixes or antidotes to known vulnerabilities and releasing them to the public. Agencies must remain vigilant to ensure that they capture all relevant fixes as they are released, test their implementation for adverse effects, and implement them after testing is concluded. Patching is associated with phases 2, 3, and 4 of the life cycle. In phase 2 , patch management relates to risk management to prevent any vulnerability from being exploited and compromised. Phase 3 contains the testing to ensure that patching and any other changes do not negatively affect the system. In general, configuration and change management should not interfere with use of the technology. One person on the security team should be appointed as the configuration manager or change manager and made responsible for maintaining appropriate data elements in the organization's cataloging mechanism, such as the specific version, revision date, and build associated with each piece of implemented hardware and software. In some cases, someone outside the implementation process might be better suited to this role because he might not be distracted by the installation, configuration, and troubleshooting of the new implementation. In the case of minor revisions, it may be simpler to have a procedure that requires documenting the machines on which a revision is installed, the date and time of the installation, and the name of the installer. While the documentation procedures required for configuration and change management may seem onerous, they enable security teams to quickly and accurately determine exactly which systems are affected when a new vulnerability arises. When stored in a comprehensive database with risk, threat, and attack information, configuration information enables organizations to respond quickly to new and rapidly changing threats and attacks. The Security Maintenance Model While management models such as the ISO 27000 series and NIST SP 800 - 100, Information Security Handbook: A Guide for Managers, deal with methods to manage and operate systems, a maintenance model is designed to focus the organization's effort on maintaining systems. Figure 11- 2 illustrates an approach recommended for dealing with change caused by information security maintenance. The figure diagrams a full maintenance program and serves as a framework for the discussion that follows. The recommended maintenance model is based on five subject areas or domains: • External monitoring • Internal monitoring • Planning and risk assessment • Vulnerability assessment and remediation • Readiness and review The following sections explore each of these domains and their interactions. 587 CHAPTER 11 Secur ity Ma intena n ce External monitoring Internal monitoring Planning and risk assessment Risk, tllreat, and attack database Readiness and review '------> Vulnerability assessment and remediation Vulnerability database Figure 11-2 The maintenance model Monitoring the Externa l Environment I KeyTerm external monitoring domain The component of the maintenance model that focuses on evaluating external threats to the organization's information assets. The objective of th e external monitoring domain within the maintenance model is to provide early awareness of new and emerging threats, threat agents, vulnerabilities, and attacks so the organization can mount an effective and timely defense. Figure 11-3 shows the primary components of the external monitoring process. External monitoring entails forming intelligence from various data sources and giving that intelligence context and meaning for use by decision makers within the organization. Data Sources Acquiring data about threats, threat agents, vulnerabilities, and attacks is not difficult. There are many sources of raw intelligence and relatively few costs associated with gathering it. The challenge is turning this flood of good and timely data into information that decision malcers can use. For this reason, many organizations outsource this component of the maintenance model. Service providers can provide a tailored supply of processed intelligence to organizations that can afford their subscription fees. CHAPTER 11 Security Ma intenance ' Vendors inform team of productrelated threats Security team scans external envirooment for threats Team feeds data to organization's database + Risk, threat, and attack database Figure 11-3 CERTs supply infOlmation on local and international threats Public Internet sites supply information on current attacks Membership sites offer value-added cootext and filtering capabilities External monitoring As shown in Figure 11- 3, external intelligence can come from these classes of sources: • Vendors- When an organization uses specific hardware and software as part of its information security program, the vendor often provides either direct support or indirect tools that allow user communities to support each other. This support often includes intelligence on emerging threats. An added complication occurs when companies use outsourcing vendors and managed service providers. The roles of these vendors in situational monitoring should be explicitly defined in the service contract. • CERT organizations- Computer emergency response teams {CERTs) exist in varying forms around the world. Often, US -CERT (www.us-cert.gov) is viewed as the definitive authority. Many states have CERT agencies, and many countries have CERT organizations to deal with national issues and threats. Your local, state, or national government may have a CERT outreach program to provide notification services at no direct cost. The U.S. Department of Homeland Security (OHS) works with the CERT/CC program at Carnegie Mellon University to provide the services at US-CERT. • Public network sources-Many publicly accessible information sources, including mailing lists and Web sites, are freely available to organizations and people who have the time and expertise to use them. Table 11-4 lists some of these information security intelligence sources. 589 CHAPTER 11 Secur ity Ma in tena n ce • Membership sites- Various groups and organizations provide value to subscribers by adding contextual detail to publicly report ed events and offering filtering capabilities that allow subscri bers to quickly pinpoint the possibl e impact to their own organizati ons. I Table 11-4 Externa l Intelligence Sources Source Name Type Comment s US-CERT Web site, mailing list, news The CERT Coo rdination Center (CERT/CC), in conjunction with t he U.S. Department of Homeland Security (DHS), provides t he National Cyber Awa reness Syst em, which can send e-mail advisories and supporting informat ion to registered organizations and individuals. You can se lect the type of notificat ions you need and regist er for t he desired advisory list at www.us-cert.gov/ncas. Links to other resou rces are provided at www.us-cert.gov/related-resources. National Vulnerability Database Web site, news, dat a feeds The U.S. government repository, hosted by NIST and sponsored by OHS, USCERT, and t he NCCIC, is an online repository for vu lnerability management data. The content of the site can be used t o support aut omation of vulnerability det ection. NVD includes several databases of security-relat ed software flaws, inf ormation on misconfigurat ions, checklists for assessment of vu lnerabilities, and ot her related content like impact metri cs. The contents of th is database are synchron ized w ith t he cve.mitre.org database. Available at nvd.nist.gov. CERT/CC Web site, biogs, news CERT/CC is a center of Internet secu rity expertise at the Software Engineering Institut e, a f ederally funded research and development cent er operated by Carnegie Mellon Unive rsity. CERT/CC and OHS support the Web site, which is usually considered the definitive author ity to be consulted when emerging th reats become demonstrat ed vulnerabilities. See CERT/CC's home page at www.cert.org. InfraGard Membership Web site, mailing list lnfraGard is a partnership between the FBI and members of the privat e sector. The lnfraGard program provides a vehicle f or seamless public/private collaboration w ith government that expedites the t imely exchange of information and promotes lea rning opport unit ies for prot ect ing critical infrastructure. With thousands of vetted members nationally, lnfraGard's membership includes business executives, ent repreneurs, military and government officials, computer prof essionals, academics, and st ate and loca l law enforcement; all are dedicated t o contributing industry-specific insight and advancing national secu rity. Today, there are approximately 50,000 members in 84 local member alliances. For more det ails, go t o https:llwww.infragard.org/. CHAPTER 11 lJ~·· . ' Security Ma intenance External Intelligence Sources (continued) Source Name Type Comments IBM's X-Force Web site, news A commercial site with a focus on the vendor's own commercial IDPS and other secur ity products. The site also provides breaking news about emerging threats, and all ows individuals t o subscrib e to alerts. See www.ibm.com/ securitylxforce/resources.html, formerly IBM's Internet Security Systems (ISS). lnsecure.org Web site, mailing list s, blog lnsecure.org is t he creation of the well -known "white-hat hacker" Fyodor. He and his associates operate t he site and p rovide the Internet community with software (Nmap is the best known of the insecure.org t ools) and information about vulnerabilities. Many topics are covered in the available lists at sec/ists.org. Mitre Web site, news The dictionary of Common Vulnerabilities and Exploits (see cve.mitre.org) is an online database managed by the Mitre Corporation. Available from the site is information and news on current vulnerabilities and related exploitation met hods. Packet Storm News A commercial site providing news and discussion focusing on current security events and tools (see packetstormsecurity.com). Secu rityFocus Web site, mailing list s A commercial site providing general coverage and comment ary on information security (see www.securityfocus.com). The site includes multiple information sou rces: • Bugtraq mailing list-The industry st andard repository of detailed, full -disclosure discussions and announcements about computer security vulnerabilities. There are also mult iple mailing lists of specialized categories under Bugtraq, like Focus on Microsoft, Focus on Apple, Focus on Virus, and Forensics. • The SecurityFocus Vulnerability Database • Dozens of SecurityFocus Mailing Lists Snort Mailing list and biogs Includes announcements and discussion of Snort, an open-source IDPS. Th e available lists (Users, SIGs, Developers, and OpenAppld) include discussions and information about the program and its rule sets and signatures. This site can be a useful source for information about detecting emerging threats. Individuals can view these lists and biogs at www.snort.org/community. SourceForge Biogs SourceForge.net maintains a large number of biogs and downloadable products f or open-source software w ith integral comments. To search for a part icu lar top ic, visit https:/1 sourceforge.net. (continues) CHAPTER 11 Secur ity Ma in tena n ce External Intelligence Sources (continued) Source Name Type Comments Tenable Tenable's Web site ded icated to the Nessus vu lnerab ility scanner. The Nessus Web site has information about emerging threats and how to test for them. The blog is at WWW.tenable. com/taxonomylterm/349. For product information, see Web blog www.tenable.com/products/nessus-vulnerability-scanner. Bugtraq Mailing list, Web resource A set of moderated mailing lists, provided by SecurityFocus, full of detailed, fu ll-disclosure discussions and announcements about computer security vulnerabil ities. The primary mail ing list, called Bugtraq, provides time-sensitive coverage of emerging vu lnerabilities, documenting how they are exploited and reporting on how to remediate them. Individuals can register for the flagship mailing list or any one of the enti re family of Bugtraq maili ng lists at www.securityfocus.com/ archive. Note@ For more information about the joint US-CERT program sponsored by OHS and CERT-CC, visit the Web site at www.us-cert.gov/about-us. Regardless of where or how external monitoring data is collected, it is not useful unless it is analyzed in the context of the organization's security environment . To perform this evaluation and take appropriate actions in a timely fashion, the CISO must: • Staff the function with people who understand the technical aspects of information security, have a com prehensive understanding of the organization's complete IT infrastructure, and have a thorough grounding in the organization's business operations. • Provide documented and repeatable procedures. • Train the primary and backup staff assigned to perform the monitoring tasks. • Equip assigned staff with proper access and tools to perform the monitoring function. • Cultivate expertise among monitoring analysts so they can cull meaningful summaries and actionable alerts from the vast flow of raw intelligence. • Develop suitable communications methods for moving processed intelligence to designated internal decision makers in all three communities of interest - IT, information security, and general management. • Integrate the incident response plan with the results of the external monitoring process to produce appropriate, timely responses. I CHAPTER 11 Secu rity Ma intenance ' • Clearly identify in corporate policy whether managed services are monitored by the organization or by the vendor providing the services. • Specify how embedded systems (also called the Internet of Things) are monitored for vulnerabilities. Monitoring, Escalation, and Incident Response The basic function of the external monitoring process is to monitor activity; report results, and escalate warnings. The best approach for escalation is based on a thorough integration of the monitoring process into the !RP, as you learned in Chapter 10. The monitoring process has three primary deliverables: • Specific warning bulletins issued when developing threats and specific attacks pose a measurable risk to the organization. The bulletins should assign a meaningful risk level to th e threat to help decision makers in the organization formulate the appropriate response. • Periodic summaries of external information. The summaries present statistical results, such as the number of new or revised CERT advisories per month , or itemized lists of significant new vulnerabilities. • Detailed intelligence on the highest risk warnings. This information prepares the way for detection and remediation of vulnerabilities in the later steps of vulnerability assessment. This intelligence can include identifying which vendor updates apply to specific vulnerabilities and which types of defenses have been found to work against the specific vulnerabilities reported. Data Collection and Management Over time, the external monitoring processes should capture information about the external environment in a format that can be referenced throughout the organization as threats emerge and then referenced for historical use. This data collection can use e-mail, Web pages, databases, or even paper-and-pencil recording methods, as long as the essential facts are communicated, stored, and used to create queries when needed. In the final analysis, external monitoring collects raw intelligence, filters it for relevance to the organization, assigns it a relative risk impact, and communicates these findings to decision makers in time to make a difference. Monitoring the Internal Environment Key Terms difference analysis A procedu re that compa res the current state of a network segment against a known previous state of the same network segment (the baseline of systems and services). internal monitoring domain The component of the ma intenance model that focuses on identifying. assessing. and managing the configuration and status of information assets in an organization. 593 CHAPTER 11 Secur ity Ma in tenance The primary goal of the internal monitoring domain is an informed awareness of the state of the organization's networks, information systems, and information security defenses. This awareness must be communicated and documented, especially for components that are exposed to the external network. Internal monitoring is accomplished by: • Building and maintaining an inventory of network devices and channels, IT infrastructure and applications, and elements of information security infrastructure. • Leading the IT governance process within the organization to integrate the inevitable changes found in all network, IT, and information security programs. • Monitoring IT activity in real time using IDPSs to detect and respond to actions or events that introduce risk to the organization's information assets. • Monitoring the internal state of the organization's networks and systems. An ongoing review of network and system devices that are online at any given moment is needed to maintain awareness of risks from new and emerging threats. The review should cover all active services, but focus extra scrutiny on the newest services offered on the network. This review can be accomplished through automated difference-detection methods that identify variances introduced to the network or system hardware and software. The value of internal monitoring is increased when knowledge gained from the network and systems configuration is fed into the vulnerability assessment and remediation maintenance domain. However, this knowledge becomes invaluable when incident response processes are fully integrated with the monitoring processes. Figure 11-4 shows the component processes of the internal monitoring domain, which are discussed in the sections that follow. Network Characterization and Inventory Organizations should have and maintain a carefully planned and fully populated inventory of all their network devices, communication channels, and computing devices. This inventory should include server hardware, desktop hardware, and software, including operating systems and applications. The inventory should also include partner interconnections- network devices, communications channels, and applications that may not be owned by the organization, but are essential to its continued partnership with another company. The process of collecting this information is often referred to as characterization. Note@ As reported by journalist Brian Krebs, a high-profile data breach at Target stores was traced back to network credentials that were stolen from a refrigeration, heating. and air conditioning subcontractor. Read more at https:llkrebsonsecurity.coml?s=target+breach. CHAPTER 11 Secu rity Ma in tenance lnvento,y network and IT infrastructure Monitor IT activity with intrusioo detectioo system Security team scans internal envirooment for threats Verify IPaddress from within Verify IPaddress from outside Team feeds data to organization's database • D Participate in IT management, change cootrol process, and architectural review boards Risk, threat, and anacl: database D< ,I Figure 11-4 interna l monitoring Once the characteristics of the network environment have been identified and collected as data, they must be carefully organized and stored using a manual or automated mechanism that allows for timely retrieval and rapid integration of disparate facts. For all but the smallest network environments, this requires a relational database. The attributes of network devices, such as systems, switches, and gateways, were discussed in earlier chapters. In contrast to the attributes collected for risk management, which are important for economic and business value, the characteristics collected here- manufacturer and software versions- relate to technical functionality, so they should be kept accurate and up to date. Also, the technology needed to store this data should be stand-alone and portable because if the data is needed to support incident response and disaster recovery, server or network access may be unavailable. Making IDPSs Wor k To be used most effectively, the information that comes from an !DPS must be integrated into the maintenance process. An !DPS generates a seemingly endless flow of alert messages that often have little bearing on the immediate effectiveness of the information security program. Except for an occasional real-time alert that is not a false positive, the !DPS reports events that have already occurred. Given this, the most important value of raw intelligence provided by the !DPS is that it can be used to prevent future attacks by indicating current or imminent vulnerabilities. Whether the organization outsources !DPS monitoring, staffs !DPS monitoring 24/7, staffs !DPS CHAPTER 11 Secur ity Ma in tena n ce monitoring during business hours, or merely ignores the real-time alerts from the !DPS, the log files from the !DPS engines can be mined for information that can be added to the internal monitoring knowledge base. Another element of !DPS monitoring is traffic analysis. Analyzing the traffic that flows through a system and its associated devices can often be a critically important process because the traffic identifies the most frequently used devices. Also, analyzing attack signatures from unsuccessful system attacks can help identify weaknesses in various security efforts. An example of the type of vulnerability exposed by traffic analysis occurs when an organization tries to determine if all its device signatures have been adequately masked. In general, the default configuration setting of many network devices allows them to respond to any request with a device signature message that identifies the device's make and model and perhaps even its software version. In the interest of greater security, many organizations require that all devices be reconfigured to conceal their device signatures. Suppose that an organization performs an analysis of unsuccessful attacks and discovers that lesser-known UNIX attacks are being launched against one of its servers. This discovery might inform the organization that the server under attack is responding to requests for OS type with its device signature. Detect ing Differen ces One approach that can improve the awareness of the information security function uses a process known as difference analysis to quickly identify changes to the internal environment. Any unexpected differences between the current state and the baseline state could indicate trouble. Table 11-5 shows how several kinds of difference analyses can be used. Note that the table lists suggestions for possible difference analyses; each organization should identify the differences it wants to measure and its criteria for action. Table 11-5 Types of Differe nce Analysis Suggested Frequen cy Method of Analysis Quarterly Dat a Source Pu rpose Manual Firewa ll rules and logs Quarterly Manual Edge router rules and logs Quarterly Manual Internet footprint To verify that new rules follow all risk assessment and procedural approvals; identify illicit rules; ensu re removal of expired rules; and detect tampering To verify that new rules follow all risk assessment and procedural approvals; identify illicit rules; ensu re removal of expi red rules; and detect tampering To verify that public Internet addresses registered to the organization are accurate and complete CHAPTER 11 I Table 11-5 Security Ma in tenance Types of Difference Analysis (continued) Suggested Frequency Method of Ana lysis Monthly Data Source Pu rpose Automated Fingerprint all IP addresses To verify that only known and authorized devices offering critical services can be reached from the internal network Weekly Automated To verify that only known and approved services are offered from critical servers in the internal network Da ily Automated Fingerprint services on critical serve rs on the internal network Fingerprint all IP addresses from the outside Hou rly Automated To verify that only known and approved servers and other devices can be reached from the pub lic network Fingerprint To enable e-mail notification of services on critical administ rators if unexpected services become available on critical servers servers exposed exposed to the Internet to the Internet The value of difference analysis depends on the quality of the baseline, which is the initial snapshot portion of the difference comparison. The value of the analysis also depends on the degree to which the notification of discovered differences can induce action. Planning and Risk Assessment Key Term planning and risk assessment domain The component of the ma intenance model that focuses on identifying and plann ing ongoing information security activities and identifying and managing risks introduced through IT information security projects. The primary objective of the planning and risk assessment domain is to keep lookout over the entire information security program, in part by identifying and planning ongoing information security activities that further reduce risk. In fact, the bulk of the security management maintenance model could fit in this domain. Also, the risk assessment group identifies and documents risks introduced both by IT projects and CHAPTER 11 Secur ity Ma intena n ce information security projects. It also identifies and documents risks that may be latent in the present environment. The primary objectives of this domain are as follows: • Establishing a formal review process for the information security program that complements and supports both IT planning and strategic planning • Instituting formal project identification, selection, planning, and management processes for follow-up activities that augment the current information security program • Coordinating with IT project teams to introduce risk assessment and review for all IT projects so that risks introduced by the launches of new IT projects are identified, documented, and factored into decisions about th e projects • Integrating a mindset of risk assessment throughout the organization that encourages other departments to perform risk assessment activities when any technology system is implemented or modified Figure 11-5 illustrates the relationships between the components of this maintenance domain. Note that there are two pivotal processes: the planning needed for information security programs and evaluation of current risks using operational risk assessment. Security team assesses its own program .. ......--< Evaluates risks introduced by new IT projects Assesses operational risks Security team evaluates current risks within the organization and develops plans and processes 1---+ Team feeds data to organization's database i Risk assessment process for IT projects Figure 11-5 Plogram review process for security department Risk, threat, and attack database Planning and r isk assessment Information Security Program Planning and Review An organization should periodically review its ongoing information security program and any planning for enhancements and extensions. The strategic planning process should examine th e future IT needs of the organization and their impact on information security. CHAPTER 11 Security Ma in te n ance A recommended approach is to take advantage of the fact that most larger organizations have annual capital budget planning cycles. Thus, the IT group can develop an annual list of project ideas for planning and then prepare an estimate for the effort needed to complete them, the estimated amount of capital required, and a preliminary assessment of the risks associated with performing each project or not. These assessments become part of the organization's project-planning process. When capital and expense budgets are made final, the projects to be funded are chosen using the planning information on hand. This allows executives to make informed decisions about which projects to fund. The IT group then follows up with quarterly reviews of progress, which include an updated project risk assessment. As each project nears completion, an operational risk assessment group reviews the impact of the project on the organization's risk profile. The sponsors of the project and perhaps other executives then determine if the risk level is acceptable, if the project requires additional risk remediation, or if the project must be aborted. Projects that organizations might fund to maintain, extend, or enhance the information security program will arise in almost every planning cycle. Larger information security projects should be broken into smaller, incremental projects, which is important for several reasons: • Smaller projects tend to have more manageable impacts on the networks and users. Larger projects tend to complicate the change control process in the implementation phase. • Shorter planning, development, and implementation schedules reduce uncertainty for IT planners and financial sponsors. • Most large projects can easily be broken into smaller projects, giving the security team more opportunities to change direction and gain flexibility as events occur and circumstances change. Security Risk Assessments A key component in the engine that drives change in the information security program is a relatively straightforward process called a risk assessment (RA), which was described in detail in Chapters 6 and 7. The RA is a method of identifying and documenting the risk that a project, process, or action introduces to the organization, and it may also offer suggestions for controls that can reduce the risk. The information security group coordinates the preparation of many types of RA documents, including the following: • Network connectivity RA - Used to respond to network change requests and network architectural design proposals. It may be part of a business partner's RA or be used to support it. • Business partner RA - Used to help evaluate a proposal for connectivity with business partners. Note that business partner risks extend beyond the direct contractual relationship to include the partner's vendors, landlords, and other clients. For instance, a cloud vendor may outsource some or all data center operations to a third party, which in tum may lease physical space in part of a CHAPTER 11 Secur ity Ma intena nce building. In such an arrangement, part of physical security may be managed by a simple leasing arrangement, not by a professional data center security team. • Application RA - Used at various stages in the life cycle of a business application. Its content depends on the project's position in the life cycle when the RA is prepared. Usually. multiple RA documents are prepared at different stages. The definitive version is prepared as the application is readied for conversion to production. • Vulnerability RA - Used to help communicate the background, details, and proposed remediation as vulnerabilities emerge or change over time. • Privacy RA- Used to document applications or systems that contain protected personal information that must be evaluated for compliance with the organization's privacy policies and relevant laws. • Acquisition or divesture RA -Used when planning for reorganization as units of the organization are acquired, divested, or moved. • Other RA- Used when a statement about risk is needed for any project, proposal, or fault that is not contained in the preceding list. The RA process identifies risks and proposes controls. Most training programs on information security include training sessions for the preparation of RA documents. A risk assessment's identification of systemic or latent vulnerabilities that introduce risk to the organization can provide the opportunity to create a proposal for an information security project. When used as part of a complete risk management maintenance process, the RA can be a powerful and flexible tool that helps identify and document risk and remediate the underlying vulnerabilities that expose the organization to risks of loss. Vulnerability Assessment and Remediation • ill f Internet vulnerability assessment An assessment approach designed to find and document vulnerabilities that may be present in the organization's public network. intra net vu lnerability assessment An assessment approach designed to find and document selected vulnerabilities that are likely to be present on the organization's internal network. penetration testing Aset of security tests and evaluations that simulate attacks by a hacker or other malicious external source. plat form security validation (PSV) An assessment approach designed to find and document vulnerabilities that may be present because misconfigured systems are used with in the organization. remediation The processes of removing or repairing flaws in information assets that cause a vu lnerability or removing the risk associated with the vulnerability. CHAPTER 11 Security Ma intenance .' 601 vulnerabi lity assessment (VA) The process of identifying and documenting specific and provable flaws in the organization's information asset environment. vulnerabi lity assessment and remediation domain The component of the ma intenance model focused on identifying specific, documented vulnerabilities and remediating them in a timely fashion. war driving The use of mobile scanning techniques to identify open wireless access points. wireless vu lnerability assessment An assessment approach designed to find and document vulnerabilities that may be present in the organization's wireless local area networks. The primary goal of the vulnerab ility assessment and remediation domain is to identify specific, documented vulnerabilities and remediate them in a timely fashion. This is accomplished by: • Using documented vulnerability assessment procedures to safely collect intelligence about internal and public networks; platforms, including servers, desktops, and process control; and wireless network systems • Documenting background information and providing tested remediation procedures for reported vulnerabilities • Tracking vulnerabilities from the time they are identified until they are remediated or the risk of loss has been accepted by an authorized member of management • Communicating vulnerability information, including an estimate of the risk and detailed remediation plans to the owners of vulnerable systems • Reporting on the status of vulnerabilities that have been identified • Ensuring that the proper level of management is involved in deciding to accept the risk of loss associated with unrepaired vulnerabilities Figure n - 6 illustrates the process flow of the vulnerability assessment and remediation domain. Using the inventory of environment characteristics stored in the risk, threat, and attack database, the vulnerability assessment identifies and documents vulnerabilities. They are stored, tracked, and reported in the vulnerability database until they are remediated. As shown in Figure 11- 6, there are four common vu lne ra bility assessment (VA) processes: Internet VA, intranet VA, platform security validation, and wireless VA. While the exact procedures associated with each can vary, these four processes can help many organizations balance the intrusiveness of vulnerability assessment with the need for a stable and effective production environment. Some organizations pursue a strategy of monthly vulnerability assessments that involve all four processes. Others perform an Internet vulnerability assessment every week and rotate the other three processes on a monthly or quarterly basis. These choices depend on the quantity and quality of resources dedicated to vulnerability assessments. CHAPTER 11 Secur ity Ma in tena n ce Extract vulnerabilities from the nsk, threat, and attack database Internet vulnerability assessment Intranet vulnerability assessment Platform security validation Wireless vulnerability assessment _. _ . Vulnerability Extract ...._ database - relevant _ ., data Develop remediation plan Figure 11-6 Vulnera bility assessment and remediation Note@ For a list of the "top 125 security tools," including vulnerability assessment tools, visit sectools.org, a Web site hosted by insecure.org. Penetration Test ing Penetration testing is a level of sophistication beyond vulnerability testing. A penetration test, or pen test, is usually performed periodically as part of a full security audit. In most security tests, such as vulnerability assessments, great care is taken not to disrupt normal business operations, but in pen testing, the analyst tries to get as far as possible by simulating the actions of an attacker. Unlike the attacker, however, the pen tester's ultimate responsibility is to identify weaknesses in the security of th e organization's systems and networks and then present findings to the system's owners in a detailed report. While vulnerability testing is usually performed inside the organization's security perimeter with complete knowledge of the networks' configuration and operations, pen testing can be conducted in one of two ways- black box pen testing and white box pen testing. In black box pen testing, or blind testing, the "attacker" has no prior knowledge of the systems or network configurations and thus must investigate the organization's information infrastructure from scratch. In white box testing, also known as full-disclosure testing, the organization provides information about the I CHAPTER 11 Security Ma inte nance systems to be examined, allowing for a faster, more focused test. White box pen testing is typically used when a specific system or network segment is suspect and the organization wants the pen tester to focus on a particular aspect of th e target. Variations of black box and white box testing, known as grey box or partial-disclosure tests, involve partial knowledge of the organization's infrastructure. Organizations often hire private security firms or consultants to perform penetration testing for a number of reasons: • The "attacker" would have little knowledge of the inner working and configuration of the systems and network other than that provided by the organization, resulting in a more realistic attack. • Unlike vulnerability assessment testing, penetration testing is a highly skilled operation, requiring levels of expertise beyond that of the average security professional. • Also unlike vulnerability assessment testing, penetration testing requires customized attacks instead of standard, preconfigured scripts and utilities. • External consultants have no vested interest in the outcome of the testing and are thus in a position to offer more honest, critical reports. A common methodology for pen testing is found in the Open Source Security Testing Methodology Manual {OSSTMM), a manual on security testing and analysis created by Pete Herzog and provided by ISECOM, the nonprofit Institute for Security and Open Methodologies. The methodology itself, which covers what, when, and where to test, is free to use and distribute under the Open Methodology License {OML). The OSSTMM manual is free for noncommercial use and released under a Creative Commons license. Note@ For more information on OSSTMM, including manual and softwa re downloads, visit www.isecom.org/research/osstmm.html. A number of penetration testing certifications are available for people who are interested in this aspect of security testing. For example, the Information Assurance Certification Review Board (IACRB) offers pen testing certifications known as the Certified Penetration Tester {CPT) and the Certified Expert Penetration Tester {CEPT). Other penetration testing certifications and approaches use the term ethical hacking. While these penetration testing certifications and efforts are valid, the use of the term is a problem for some because hacking is often defined as unauthorized and illegal attempts to circumvent security controls. When attempts to compromise system controls are sanctioned by management, they cannot be considered hacking by definition. Because hacking is defined as illegal, it cannot be considered ethical. 603 CHAPTER 11 Secur ity Ma in tenance View Point Planning Against Attacks By Donald McCarthy, Vice President of Operations, myNetWatchman LLC Sometimes it can be useful to imagine what could happen when things go w rong. Let's imagine you were promoted to the CISO role of a healthcare company 90 days ago. Within the first month of your tenu re, an intrusion was det ected. Today you presented to the board a report on a set of cascading failures that could cost the company more than a million dollars. The digital forensics/incident response (DFIR) firm you hired found t he source of the breach 52 days ago, along with the persistence mechanism t he attackers used. A senior executive's assist ant opened an e-mail that contained a malicious payload and was detected as suspicious by the anti-virus (AV) software. During t he software's decision-making process, the payload was pa rsed in the kernel with system-level privileges. A flaw in t he AV engine led to remote code execut ion (RCE). From there, the attacker had full cont rol of the system and began post-exploitation tasks. The first pivot was to a file server. The same payload from the executive assistant's machine was copied onto the file server, yielding the same result: RCE on the file server. Loose fi rewa ll controls caused by complaints to the help desk about connect ivity issues allowed systems in the execut ive group t o talk to all systems in the network. The attacker's second pivot was to the vulnerability scanner, which had unfettered access to every piece of crit ical infrastructure for the ent ire corpo rate network. This machine also held credentials for every machine on the network. Once the attacker had credentials to all systems, there was a met hodical scan of all file shares and databases. The next series of movements gathered and exfiltrated the most sensitive data t he company possessed: pat ient data, payment card data, and plans for three upcoming hospital acquisitions. This intrusion was preventable and a failure of policy, design, and risk assessment. The initial deployment of the company's new e-mail client had the reading pane disa bled. This generated so many calls t o the help desk about e-mail problems that an emergency change was implemented to turn on the read ing pane. The RCE in the AV softwa re had been disclosed for more than a yea r. The patch requ ired a license upgrade to the AV management server and cl ient. Because t he AV clients were receiving definition updates, this expense was not viewed as critical. The vulnerability scanner had an upt ime of 710 days and was not configured to check itself. The security operat ions center (SOC) silenced the alerts generated from t he vulnerability scanner because it generated numerous fa lse positives. Data was moved from database servers, file servers, and application servers to a company Web server. From there, t he attacker used a rate-lim ited download to exfiltrate files without attracting attention. The risk assessment the company was using was modeled on keeping attackers out. There were no cont rols in place to keep data from leaving the internal network. The risk CHAPTER 11 Security Ma inte nance .' 605 assessment also never listed any of the security appliances or tools in a column other than mitigating controls. The extensive report prepa red later by the DFIR firm could be condensed to two main truths. First, the very tools meant to protect your company had been the critical enablers of the attacker. Second, the DFIRcompany fees for the past 60 days were enough to pay for 10 vulnerability servers, the salaries of four SOC ana lysts, the AV license upgrade, and salaries for 20 full-time help desk employees. This story could have happened. Th is story could be you at work. With a bit of creative thinking, we can look at networks like attackers do. It is not popular with executives to plan network defense from the perspective of ''when we will be breached," but it might well be the only way to keep data in the network and out of the hands of attackers. Intern et Vulnerability Assessm ent The Internet vulnerabil ity assessment is designed to find and document vulnerabilities that may be present in the organization's public network. Because attackers from this direction can take advantage of any flaw, this assessment is usually performed against all public addresses using every possible penetration testing approach. The steps in the process are as follows: • Planning, scheduling, and notification of penetration testing -To execute the data collection phase of this assessment, large organizations often need an entire month, using nights and weekends, but avoiding change control blackout windows - periods when changes are not allowed on the organization's systems or networks. This testing yields vast quantities of results and requires many hours of analysis, as explained in the following section. A rule of thumb is that every hour of scanning results in two to three hours of analysis. Therefore, scanning times should be spread out so that analysis is performed on fresh scanning results over the course of the assessment period. Also, the technical support communities should be given the detailed plan so they know when each device is scheduled for testing and what tests are used. This makes disruptions caused by invasive penetration testing easier to diagnose and recover from. • Target selection- Working from the network characterization elements stored in the risk, threat, and attack database, th e organization ...
Purchase answer to see full attachment
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Hey buddy! Your work is ready. Have a look at it. In case of any questions, feel free to ask.

Running Head: OUTLINE

Security Manager Responsibilities

Student’s Name:

Course Title:

Date:

OUTLINE

1

Exercise 3
Tools
1. Wireless vulnerability assessment
2. Platform security validation
3. Modem Vulnerability assessment
4. Risk assessment
5. Event log analyzers
Exercise 4
➢ One of the sites which claim to provide support to hackers is ManageEngine.
References


Running ...


Anonymous
Great! Studypool always delivers quality work.

Studypool
4.7
Indeed
4.5
Sitejabber
4.4

Related Tags