PCI DSS Goal 1: Secure By Design/Default
PCI DSS - Requirement 1: Install and maintain a firewall configuration to protect cardholder data. Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network. Other system components may provide firewall functionality, as long as they meet the minimum requirements for firewalls as defined in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.
PCI DSS - Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems.
Requirement 7: Restrict access to cardholder data by business need to know. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Requirement 8: Identify and authenticate access to system components. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes. The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.
Requirement 10: Track and monitor all access to network resources and cardholder data. Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
Requirement 11: Regularly test security systems and processes. Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
Ever since I was first deployed on Counter Intelligence Field Team (CIFT) operations, I started to appreciate the value and benefits of employing a proactive approach to the defence of mission critical assets.
However, to make this function effective we the CIFT team needed to actively engage with the stakeholders, to understand the topology of the environment and to understand the priority of the assets to be defended.
Consequently, we would be constantly referencing our base diagrams, as well as the external maps, documenting every notable event through Intelligence Reports (IntReps) and linking all associated entities into an intelligence database.
Ultimately, creating an integrated approach to protective security to ensure that appropriate threat intelligence was being fed into the defensive efforts.
In Afghanistan, the military bases would be subject to constant surveillance and periodic testing of our defences (e.g. Insurgents attempting to gain access by dressing in military or Afghan National Police (ANP) uniforms). In addition to this, on a daily basis a military base could receive upto 2,000 local nationals.
Consequently, the military bases had to be configured on zero trust, whereby everything is perceived as being a threat and the topology helps aid the filtering between the 'Badlands' to semi-trusted and trusted environments.
The insurgents were prevented from easily walking in from the desert straight upto an aircraft. To do so, they had to compromise a number of defensive layers and their abnormal activities would be detected and responded to, in order to minimise the potential impact and to make it extremely difficult for them (requiring extensive planning).
Secure By Design/Default Concept
Your network provides the foundation for creating secure silos, where your most valued business assets reside in air-gapped, isolated network segments. By enforcing strict network filtering, based upon business justified access requirements, you can help make it more difficult for an opportunist attacker.
Do you have a flat network, where you are solely reliant on the perimeter layer?
Think of your corporate network as being a military base.
Much like a military base provides physical layers of defence, with traffic filtering between trusted and untrusted, to help make your event and systems monitoring capabilities more effective you should consider the benefits of configuring your network so that it replicates the 'tried and trusted' military approach to layering the environments:
Do you filter internal network traffic that block any transmissions that do not meet specific security criteria?
Do you have network diagrams that show a clear differential between untrusted (BLACK Zone), semi-trusted (Orange Zone) and trusted (RED Zones)?
Do you data flow diagrams that clearly show the communication paths of your sensitive data assets.
Much like an aircraft pan, do you filter access the RED zones using strict firewall/router rulesets (prevent ANY ANY rules in/out of the RED zones)?
In the event that your perimeter gets compromised, how long will it take for you to identify ABNORMAL activities?
Will you be able to identify and respond to ABNORMAL activities, occurring in the BLACK and Orange Zones?
All the systems supporting your business critical operations should be 'locked-down' to prevent misuse, helping to mitigate the risks of an attacker being able to circumvent the defences by manipulating the supporting systems.
Whether you are in scope for PCI DSS, by applying the concept from Goal 1 of PCI DSS (Build and Maintain a Secure Network and Systems) for the protection of your sensitive data assets, you are able to fortify your network architecture (enhancing your defences, whilst reducing the risk of a data breach) and provide a technology measure to satisfy regulatory obligations.
GDPR Article 25 1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. 2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons. 3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
Validating your efforts
Having established a secure by design/default concept, it is essential that you have an integrated approach, whereby your assets have been identified and visualised into a layered infrastructure.
This layered infrastructure should help prevent the attackers from gaining a clandestine persistent presence within your corporate network (aka Dwell Times), reducing their opportunity to carry out hostile reconnaissance within your internal network and, thus, reducing their chances to identify ways to circumvent your RED Zone defences.
Consequently, it is extremely important for the monitoring capability to have appropriately placed IDS/IPS alerting and to understand what are the important assets, where the assets are located and to which users are authorised access.
Additionally, much like a military base, your monitoring capability should be able to identify suspicious or malicious activity working from the untrusted to the trusted environments, whilst providing an 'Chain of Evidence' audit trail.
Finally, the secure by design/default concept should be validated by testing for rogue wireless, vulnerability assessment and penetration & segmentation testing of both the external & internal networks.
This will confirm that the secure silos are working effectively.
In addition to relying solely on the penetration testing, there are a number of things you could consider to augment this integrated approach:
Automated Asset Discovery
Automated Secure Firewall/Router Configuration Checks
Automated Secure Systems Configuration Checks
Try using the output of such testing to include in your regular security metrics reporting.
Ensure that you are fully engaged with your penetration testers and that you work together to ensure that your scope is accurate and the testing is effective for confirming your defensive capabilities.
Do you understand the testers basis for penetration testing execution, e.g.
It is inevitable that your organisation will be subject to the unwanted attentions of an opportunist attacker and they will likely compromise your perimeter.
Once through your perimeter:
How quickly do you think you will identify unauthorised insurgents?
Will this be before they are able to attack your environment from within?
Will the network architecture make it sufficiently challenging for the 'wannabe' attacker?
When looking at your secure architecture, is it easy to identify 'The Good' from 'The Bad' and 'The Ugly' and does this architectural diagrams serve to help better scope the penetration testing, to confirm the effectiveness and status of the various network zones.
PCI DSS is often seen as being extremely prescriptive and difficult to achieve, and maintain. However, in reality, if you look at this from the perspective of developing military grade defences, the return on investments for safeguarding your business' valuable network-connected assets speak for themselves.
Ask yourself.... Why wouldn't you?
For this, and other insightful 'Blue Sky' thinking, check out my recently released book.