The Official (ISC)2 SSCP CBK Reference. Mike Wills. Читать онлайн. Newlib. NEWLIB.NET

Автор: Mike Wills
Издательство: John Wiley & Sons Limited
Серия:
Жанр произведения: Зарубежная компьютерная литература
Год издания: 0
isbn: 9781119874874
Скачать книгу
of what to accept, transfer, treat, or avoid

       Risk mitigation decisions, including specifics as to the chosen controls and the anticipated residual risk after the controls are put into practice

       Success criteria, in operational terms, which indicate whether the control is successfully performing its functions

       Anticipated ongoing costs and efforts to use and maintain a set of controls

       End-user and support team training, including any requalification training, needed to keep the controls operating effectively

       Continuous, ongoing monitoring of operational use of the controls

       Ongoing periodic or random assessment, including penetration testing, aimed at assessing the controls

       Decisions to upgrade, replace, or completely retire a set of controls

      As you'll see in Chapter 3, there are a number of information products generated by risk management and risk mitigation planning. Although they may be known by various names or be produced in many different formats, the core set of information includes the business impact analysis, risk assessment, risk mitigation plan, and the change management and baseline documentation for the chosen and implemented controls. These could include vendor-supplied manuals as well as your organization's own functional performance requirements allocated to a particular control.

      Effective information systems management must achieve three distinctly different goals:

       Are we spending what we need to (and no more) to achieve the right business priorities and objectives?

       Are we using our information systems effectively in ways that help us achieve our objectives?

       Are we maintaining, changing, or upgrading our information systems in effective ways to meet changing conditions and needs?

      Those three questions all focus on our information systems architecture, the elements we've brought together to create those systems with, and the business logic by which we use those systems. As we'll see in Chapter 3, having a solid baseline that captures and describes our organization's information systems and IT architecture is the foundation of how we manage those information systems. It's also worthwhile to consider that well-managed systems are often more reliable, resilient, safe and secure; unmanaged systems may be just as trustworthy, but if they are, it's more by luck than by design.

      ISO 55000 provides extensive guidance for the proper management of physical assets, including buildings, facilities, and infrastructure elements such as electrical power, plumbing, and heating, ventilation, and air conditioning (HVAC) systems. COBIT5, from ISACA (previously known as the Information Systems Audit and Control Association, but now by its acronym only), is another framework of structured guidance for information systems and information asset management, which your organization may already be using.

      Broadly speaking, an information systems asset is any element of a system for which it is useful to assess or estimate a value, a cost, and a loss or impact. The value should relate to the gains to the organization that can be realized through effective use of that asset. Costs should reflect all that was spent, including time and effort, to create or acquire, install, use, and maintain the asset. The loss or impact can reflect either the replacement cost, the decrease in value, or some other assessment of how damage, destruction, or degradation of the asset will affect the organization.

      Nominally, an asset has one point of management: You manage a single server or you manage a data center, but two data centers integrated via a VPN connection supported by a third party is most likely easier to manage as a set of related assets.

      Parts or Assets?

      At some point it is easier and more meaningful to track and manage a system as an asset but consider all of the replaceable bits and pieces of it as units or parts. Your network backbone, for example, may consist of high-capacity, redundant routing and switching elements tied together with fiber, cable, WiFi, or other media. As a system, it's useful to track it as an asset, while having a logically distinct inventory of its spare parts.

      Asset Inventory

      Information systems asset management starts with the asset inventory, which must completely and unambiguously identify every information systems element to be managed as an asset. The inventory should include hardware, firmware, software, virtual machine environments, cloud systems services, databases, websites, and the supporting documentation for end users and maintainers.

      Having a current and complete inventory is the absolute bedrock for implementing and monitoring technical security controls.

      Note that almost any device that can attempt to access your networks or systems is an object to be inventoried, placed under configuration control, and incorporated into your access control systems' databases as an authenticated identity. Failing to tie these three processes together—and keep them tied together—leaves an unnecessary degree of access open to potential intruders.

      Inventory Tool/System of Record

      Because of the size, complexity, and frequency of the task, an organization should use automated tools to assist in creating and maintaining the asset inventory. The tools should have awareness of all assets in the organization's enterprise and the ability to discover new assets introduced to the environment that have not been properly documented in the inventory. This data comes from either an asset management agent or a client installed on each asset or “baked in” to each system image. It can also be generated with various scanner and sensor tools, or, in the case of hosted or cloud assets, from a data feed or recurring report from the vendor (which may or may not be shared with clients, depending on the terms of their service-level agreements [SLAs] or terms of reference [TORs] with their clients).

      An asset inventory tool should have a way to distinguish authorized devices and applications from unauthorized devices and an ability to send alerts when the latter are discovered. The tool should also collect and track individual asset details necessary for reporting, audits, risk management, and incident management. These details need to cover technical specifications, such as the following:

       HardwareManufacturerModel numberSerial numberPhysical locationNumber and type of processorsMemory sizeNetwork interfaces and their MACs and IPsHostnameHypervisor, operating systems, containers, virtual images running on this devicePurchase date, warranty informationLast update dates (firmware, hypervisor, etc.)Asset usage metrics

       SoftwarePublisherVersion