Protective Security or Boiling The Ocean
With the increasing pressures on business to ensure that they are secure and have a reduced risk of suffering a data breach, the application of a suitable controls framework (e.g. ISO27001, ISO27701, NIST CSF, PCI DSS, CIS 20 CSCs, NIST SP800-53, ISF SoGP, NIST SP 800-82, etc.) can often feel like 'Boiling The Ocean'.
The reason is often caused through a lack of communication between the business and the Cyber/InfoSec teams. As a result, the business fails to identify the their most critical business assets (those assets that support essential business services or are involved in the processing of sensitive data) and meaning that the diligent Cyber/InfoSec teams need to try and interpret the scope of the assets that need to be safeguarded for Confidentiality, Integrity and Availability (CIA).
Consequently, it is essential for businesses (no matter the size of the organisation) to identify, categorise and manage the assets that are prioritised for defence, across their individual system life-cycles:
Failure to identify the business' scope significantly increases the risks of an essential or impact system being overlooked and being left vulnerable to an attack, whilst lesser systems are prioritised.
Equifax was one such cyber attack that clearly demonstrated the value of effective asset management and how this can undermine any defensive efforts:
"The Canadian credit card information of individuals who purchased certain direct-to-consumer products or fraud alerts by phone was, at the time, held by Equifax Inc. in a database that had not been included in the scope of Equifax Inc.’s annual Payment Card Industry Data Security Standard (PCI-DSS) certification. Industry standards require that this certification cover all systems used by an organization to handle credit card information. The forensic third party hired by Equifax Inc. which conducted an analysis after the breach, found deficiencies in compliance with the PCI-DSS standard".
I first introduced to the term 'Protective Security' during my 10-week residential Counter Intelligence course, in 2002.
Protective security is the protection of assets from compromise, which can be a breach of:
Confidentiality. The restriction of information and other valuable assets to authorised individuals (e.g. protection from espionage, eavesdropping, leaks and computer hacking).
Integrity. The maintenance of information systems of all kinds and physical assets in their complete and usable form (e.g. protection from unauthorised alteration to a computer programme).
Availability. The permitting of continuous or timely access to information systems or physical assets by authorised users (e.g. protection from sabotage, malicious damage, theft, fire and flood).
In assessing integrity and availability, consideration must be given to both the direct and indirect consequences of compromise.
Assets are defined as "anything of value, either tangible or intangible that is owned or used by an organisation or business". They can be:
Documents and information;
Material such as buildings, equipment, valuables or cash;
Operating systems or;
Material assets can have different degrees of value and need to be identified and categorised based upon the businesses perceived values. This will ensure that effective security controls can be applied to help mitigate the risks:
Based upon my training and experiences of delivering protective security in the RAF Police, as well as my experiences working in the corporate sector, I developed a 7-step project management based model (known as PIE FARM):
Step 2 of this model involves a focus on asset identification (further explanations/details available at Chapter 12 - PCI DSS: An Integrated Data Security Standard Guide) and can also be seen as an integral element of the various industry security standards/frameworks:
Asset Management is an essential component for effective scoping, which is an integral part of a protective security or compliance program.
For example, PCI DSS describes scoping as follows:
"The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications. Examples of system components include but are not limited to the following:
Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.
Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.
Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.
Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).
Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.
Any other component or device located within or connected to the CDE.
The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope. All types of systems and locations should be considered as part of the scoping process, including backup/recovery sites and failover systems.
To confirm the accuracy of the defined CDE, perform the following:
The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.
Once all locations of cardholder data are identified and documented, the entity uses the results to verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).
The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If the entity identifies data that is not currently included in the CDE, such data should be securely deleted, migrated into the currently defined CDE, or the CDE redefined to include this data.
The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity.
For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented".
It is important that you understand the assets that you need to safeguard and that these assets are documented and managed through an asset inventory, correlated against support network diagrams and communication/data flow diagrams.
Without effective asset management, it will be extremely difficult to implement and manage your defensive strategies, and understand the risks to your business operations.
Additionally, if your objective is to safeguard payment card security, an effective asset management process is essential to effective vulnerability management, to ensure that you can align with any significant changes:
NIST SP 800-37 Rev 2 describes a significant change as being:
"A change that is likely to substantively affect the security or privacy posture of a system. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:
Installation of a new or upgraded operating system, middleware component, or application;
Modifications to system ports, protocols, or services;
Installation of a new or upgraded hardware platform;
Modifications to how information, including PII, is processed;
Modifications to cryptographic modules or services; or
Modifications to security and privacy controls.
Significant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:
Moving to a new facility;
Adding new core missions or business functions;
Acquiring specific and credible threat information that the organization is being targeted by a threat source; or
Establishing new/modified laws, directives, policies, or regulations".
Do you understand the various layers, how the systems inter-connect and how the data flows through your network, as per the OSI Model?
Consider the potential benefits of automating the asset management process (e.g. ExtraHop) or carrying out periodic asset discovery scans (e.g. Qualys, Security Scorecard, etc.) and incorporating periodic reviews into your internal audit process. This will provide multiple benefits:
Ensure all critical devices are included in the scope.
Support the change management of End of Life(EoL)/End of Support(EoS) hardware and software.
Support the risk assessment, within the vulnerability management processes.
Mitigate the presence of rogue devices.
Support the resilience strategies.
Ensure Asset Management is at the heart of the protective security or compliance strategies by prioritising and measuring the effectiveness and maturity of an organisation's asset management process is vital to the success or failure of a protective security strategy. Consequently, it is essential that the 3 Lines of Defence understand what is important to protect and, remember, that this is not limited to IT systems.
Understanding this can significantly increase the effectiveness of your defensive efforts and to help ensure that you understand the risks that pertain to the assets' values.