Month: October 2022

What security requirements does the GDPR have?

Posted on by admin
This article is part of our GDPR compliance certification hub page, where we explain how GDPR supports stronger data protection and privacy compliance. This blog focuses on the security requirements under GDPR, including the need for appropriate technical and organizational measures to protect personal data from unauthorized access, accidental loss, misuse, or data breaches.

Personal data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical or organisational measures,” according to Article 5.1(f) of the GDPR. In essence, this is the security premise of the Regulation. The security of processing is governed by Article 32. Examples of suitable organisational and technical measures include:

  • encryption and pseudonymization of personal data
  • the capacity to maintain processing systems’ and services’ continued confidentiality, integrity, availability, and resilience
  • the capability of recovering data accessibility and availability in the case of a physical or technological mishap
  • a procedure for routinely examining, evaluating, and testing the efficacy of organisational and technical security measures.
Data controllers and processors must consider the risks associated with processing when deciding which security measures to put in place. A risk assessment or DPIA (data protection impact assessment) will help you choose the right security measures. Even when the risk is originally viewed as low, doing DPIAs is a useful practise because your evaluation may disclose risks you had not thought of. 
The GDPR includes six data processing principles as opposed to the eight data protection principles of the Data Protection Act of 1998. Personal information must be:
  1. “Lawfulness, fairness, and transparency” refers to how data is processed in regard to the data subject.
  2. Collected for specific, clear, and legal purposes and not further processed in a way that is inconsistent with those purposes pursuant to Article 89(1), further processing for public interest archiving, scientific or historical research, or statistical purposes shall not be deemed to be inconsistent with the initial purposes (the “purpose limitation”)
  3. Adequate, pertinent, and strictly limited to what is required in light of the processing’s goals (data minimization)
  4. Accurate and, where necessary, kept current every effort must be made to ensure that personal data that is incorrect, taking into account the purposes for which it is processed, is immediately deleted or corrected
  5. Personal data may be stored for longer periods if they are processed solely for archiving in the public interest, scientific or historical research purposes, or statistical purposes in accordance with Article 89(1), subject to implementation of the necessary technical and organisational measures. Personal data must be kept in a form that makes it possible to identify data subjects for no longer than is necessary for the purposes for which they are processed.
  6. Processed in a way that guarantees adequate security of the personal data, including protection against unauthorized or unlawful processing and against unintentional loss, destruction, or damage (referred to as “integrity and confidentiality”), using appropriate technical or organisational methods.

Six distinctions between the PCI SSF and the PA-DSS

Posted on by admin

The Payment Card Industry Software Security Framework, introduced by PCI SSC, is a relatively new framework that will go into effect in October 2022. The PCI SSF is a collection of various codes and tools created to safeguard payment software. It’s a framework that was created to take the position of the Payment Application Data Security Standard (PA-DSS) with more up-to-date standards that support various payment software types, technologies, and development techniques.

1. The PCI SSS does not contain any “prescriptive” requirements.
There are strict guidelines under PA-DSS that spell out in detail the prerequisites that the payment application must satisfy for both you and them:
  • This made it simpler for your engineers to build your product around a set of fixed controls, with your assessor only checking to see if they were implemented.
  • If they weren’t, the payment application didn’t satisfy the condition. It was either in place, it wasn’t in place, or it wasn’t applicable. The outcome was categorical.
The SSF for the PCI is unique. The standard gives vendors the freedom to choose their own specific security objectives, and your assessor will only verify the effectiveness of those controls.
  • More flexibility is desirable but has potential drawbacks.
  • Such flexibility means you’ll need to pay closer attention to your controls and win the support of your software stakeholders if you’re interested in implementing the new framework.
Unlike the PA-DSS, which always offered a binary result and did not allow compensating controls, the PCI SSS’s new objective-based methodology allows any control that reduces risk to be considered compliant.
How does that affect you? When the time for your evaluation comes, you should be prepared to back up your controls with a strong risk assessment based on their threat analysis and have a thorough grasp of how you are meeting each control target.
2. The PCI SSS’s security objective testing will be based on other goals.
If the PCI SSF gives you the option to choose your own security goals, you must make sure they are completely implemented for your assessment to be successful. It should be obvious, therefore let’s provide an example:
  • You must determine your important assets in order to conduct your assessment.
  • If certain associated objectives are not specified, it becomes an issue because the pertinent security objectives will need to be tested by your assessor using the essential assets that you specify.
  • Your assessors won’t be able to test a significant portion of your programme without each security objective in place, which is terrible for your compliance.
3. Under PCI SSS, there will be source code review.
Despite the fact that PA-DSS did not specifically mandate that assessors must conduct source code reviews, PCI SSS does.
Your assessor will conduct a source code assessment of your software, which is especially pertinent to Control Objective 5.2, to confirm the ways in which you previously specified key assets may be accessed. If you anticipate being subject to PCI SSS, you should be ready to participate in the review manually or automatically in addition to being ready for a source code review.
4. The Random Number Generator (RNG) entropy testing is part of the PCI SSS.
Your assessor will be expected to gather information from the software vendor and conduct testing to determine the robustness of the RNGs that your programme use in order to comply with the new PCI SSS.
The test specifications demand that the assessor get at least 128 MB of output data from each random number generator used in the system.
If you already know it’s difficult to access your RNG data or you’ve never given it any thought, start planning ahead and consult with your assessor to determine the best course of action.
5. There’s been a shift in language regarding documentation.
The idea of an implementation guide was first introduced by PA-DSS validation, and the PCI SSS is supposed to preserve it.
However, the semantics have changed.
The PCI SSS standards now refer to the materials you can give to achieve the goals that were once covered by a single implementation guide as “guidance documents” in order to be more inclusive.
This modification gives you the choice of providing a single implementation guide or a number of papers to fulfil the purpose during testing.
6. The PCI SSS mandates “transient sensitive data” and more thorough forensic testing.
Anyone who has undergone PA-DSS validation is familiar with forensic examinations. (Or, at the very least, it shouldn’t.)
However, the PCI SSS assessment now covers both persistent and temporary sensitive data. Your assessors will also assess potential exposure points for data:
  • Be prepared to discuss these sites where you store sensitive data, both persistent and temporary.
  • Additionally, you should be prepared to help with the setup of forensic tools in the testing environment so that your assessor can watch you securely delete sensitive data and monitor data retention.

Controls Guide for ISO 27001 – Part 2

Posted on by admin

This article is part of our ISO 27001 certification hub page, where we cover key concepts, requirements, and implementation steps for building a strong Information Security Management System. In this second part of the controls guide, we continue exploring ISO 27001 controls that help organizations manage security risks, improve compliance, and strengthen data protection practices.

What are the ISO 27001’s 14 domains?

In sections A.5 to A.18 of Annex A of ISO 27001, 14 “domains” are listed. The following is covered in the sections:

Annex A.5. Information Security Policies:  Giving management guidance for information security policies is the goal of Annex A.5. The goal of this Annex is to manage information security guidance and support in accordance with the needs of the organisation and in compliance with applicable laws and regulations. Two controls are present in the Annex:

  • A.5.1.1 Policies for Information Security  – According to Annex A.5.1.1, a set of information security policies must be established, approved by management, published, and distributed to staff members and pertinent outside parties.
  • A.5.1.2 Review of the Policies for Information Security  – The information security policies must be evaluated on a regular basis or if significant changes take place, according to Annex A.5.1.2, to ensure that they continue to function in a stable, adequate, and efficient manner.

Annex A.6. Organization of Information Security: 

  • Annex A.6.1 is about the internal organization of information security. Establishing a management framework that starts and manages the application and operation of information security is the goal of this Annex.
  • Annex A.6.1.1 Information Security Roles & Responsibilities  specifies that each and every responsibility for information security must be identified and assigned. Responsibilities for information security might be generic (like protecting information) or specific (e.g. the responsibility for granting a particular permission).

Annex A.7. Human Resource Security:

  • Annex A.7.1 is about employment and is concerned directly with human resources. Making sure that staff members are knowledgeable about their roles, well-trained, and qualified for them is the goal here. What transpires when people depart or switch responsibilities is also covered in this Annex. There are 6 controls in the Annex.

All job candidates are subjected to background checks and competence assessments. The obligations the employee and the organisation will both bear for adequate information security hygiene must be specifically stated in the contractual agreement signed by workers and contractors. The goal is to guarantee that workers and contractors understand and fulfil their information security obligations while on the job.

Annex A.8. Asset management:

Asset accountability is covered in Annex A.8.1. This Annex’s goal is to define and identify the information assets that are under the management system’s purview. They must also be given the proper protective obligations. There are 10 controls in the Annex. This Annex mandates the identification and management of all assets related to information processing facilities. Assets should be listed in a detailed inventory that outlines how they are handled and regulated.

Annex A.9. Access Control: 

  • Annex A.9.1 is about the business requirements of access control.  This Annex control’s goal is to restrict access to information and information processing infrastructure. There are 14 controls in this Annex. This Annex requires that an access control policy be created, documented, and periodically evaluated while keeping the business needs for the assets in mind. Only the networks and network services that users actually need for their jobs should be granted access to users. All user types must have access rights to all systems and services, and a procedure must be put in place to grant or withdraw those rights.

Annex A.10. Cryptography:

  • Annex A.10.1 is about Cryptographic controls. Here, protecting the confidentiality, authenticity, and/or integrity of information through the right and efficient use of cryptography is the goal. There are two controls in this Annex. A policy for the usage and security of cryptographic keys should be established in accordance with the criteria of this Annex. All stages of the keys’ life should be covered by this policy. Additionally, a procedure should be in place for the generation, transfer, modification, backup, and storage of cryptographic key material all the way up until its demise.

Annex A.11. Physical and environmental Security: 

  • Annex A.11.1 is about ensuring secure physical and environmental areas. Preventing illegal physical access, property damage, and interference with the organization’s information and information processing facilities is the goal of this Annex. There are 15 internal controls in total. For places that house either sensitive or crucial information, this Annex should include a thorough explanation of the security perimeters and bounds. This comprises locations with tools for information processing, such as computers, laptops, etc. To ensure that only authorized  people are granted access, secure locations need to be safeguarded with the proper entry restrictions. Additionally covered by this Annex are operations interruptions and asset loss, damage, theft, or compromise.

Annex A.12. Operations security:

  • Annex A.12.1 is about Operational Procedures and Responsibilities. This Annex’s goal is to guarantee the reliable and secure functioning of information processing facilities. There are 14 controls in all. Operating procedures shall be documented and made available to all users upon request in accordance with this Annex. Operating procedures that have been properly documented ensure that systems will function consistently even when additional personnel or resources are added. They are frequently essential for disaster recovery, business continuity, and when staff availability is jeopardized. Malware Defence  is also covered in this Annex. The goal is to secure data centers  and other information-processing infrastructure from malware intrusion.

Annex A.13. Communications security: 

  • Annex A.13.1 is about Network Security Management. This Annex’s goal is to guarantee the security of data in networks and the information processing facilities that enable them. There are 7 controls in this Annex. To safeguard the information included in systems and applications, networks must be monitored and under strict supervision. This means that the company needs to have procedures that guarantee the security of the data included in its systems and applications.
  • Annex A.13.2  is about information transfer. This Annex’s goal is to protect the confidentiality of information shared within the company and with any outside party, such as a client, a supplier, or other interested parties.

Annex A.14. System Acquisition, Development and Maintenance:

  • Annex A.14.1 is about security requirements of information systems. The goal is to make sure that throughout the lifecycle of information systems, sound information security procedures are maintained as a core component. This covers the specifications for information systems that offer services across open networks. There are 13 controls in this Annex. Any specifications for brand-new information systems or improvements to the current information systems must include information security-related requirements.
  • Annex A.14.2 is about process security throughout development and support. This Annex’s goal is to make sure that information security is planned for and implemented throughout the information system development lifecycle.

Annex A.15. Supplier Relationships:

  • Annex A.15.1  is about supplier relationships and information security. The goal is to safeguard the company’s priceless assets from suppliers who may have access to or influence them. This should also encompass other important relationships, such those with business partners. There are 5 controls in this Annex.
  • Annex A.15.2  is about managing Supplier Service Development. This Annex’s goal is to make sure that, in accordance with supplier agreements, a certain degree of information security and service delivery is maintained.

Annex A.16. Information Security Incident Management:

  • Annex A.16.1  is concerned with managing information security events, incidents, and weaknesses. The goal is to make sure that incidents, occurrences, and weaknesses are handled consistently and effectively throughout their lifecycle. There are 7 controls in this Annex. These controls outline how management must set up roles and processes to guarantee a prompt, efficient, and systematic response to flaws, events, and security incidents.

Annex A.17. Information Security Aspects of Business Continuity Management:

  • Annex A.17.1 Continuity of Information Security is the topic. The goal is to integrate business continuity management systems for the firm with information security continuity. There are 4 controls in this Annex. The company must ascertain its particular needs for information security and consider how information security management will continue in difficult circumstances, such as during a crisis or tragedy.

Annex A.18. Compliance: Annex

  • A.18.1  is about adhering to statutory and contractual obligations. The goal is to prevent violations of any security standards as well as of any legal, statutory, regulatory, or contractual duties linked to information security. There are 8 controls in this Annex.
  • Annex A.18.2  is about evaluations of information security. The goal is to make sure information security is run in compliance with organizational  rules and procedures.

When information like this seems overwhelming, knowledgeable cyber security companies like QRC may step in and help streamline the process. Organizations are not obligated to use all 114 of ISO 27001’s controls, as we previously discussed.  It is merely a list of things that must be done in accordance with the risk assessment made by your firm. For you and your management team, the standard serves as a roadmap for establishing, putting into place, maintaining, and continuously enhancing an effective information security management system. With all of the aforementioned basic controls in place, you’ll have a smooth procedure that will assist your company in identifying and promptly mitigating possible hazards.

Read more about this: Advantages of ISO/IEC 27701:2019 certification