The National Cybersecurity Authority (NCA) published the Essential Cybersecurity Controls framework to help government organizations protect their systems, networks, and data against cyber threats. The regulations and guidelines mandate a common approach to information security across public sector organizations, third parties involved, and private companies responsible for critical national infrastructure to help maintain a high level of security confidentiality across the industry.
The regulation requires the organizations to not implement security measures as per the guidelines but also maintain documentation and evidence of implementing the security safeguards. Let us take a look at some of the documents and evidence requirements for NCA ECC Compliance. The below-given list can work as a checklist for your organizations to consider when complying with NCA ECC Compliance.
Documentation and Evidence Checklist for NCA ECC Compliance
| Old Requirement (v3.2.1) - 7.1 | Updated Requirement (v4.0) - 7.2.1, 7.2.2, 7.2.3 |
|---|---|
| • In this version, access to system components and cardholder data was a privilege, not a right. It was only given to those individuals who needed it to do their jobs. | • This requirement is all about granting access based on what’s needed for the business, the job classification and functions of the users, and the least privileges required to perform a job function. |
| • Each role had its own defined access needs. This included the system components and data resources that each role needed for their job function, and the level of privilege required for accessing these resources (7.1.1). | • Access isn’t just given out to anyone. It’s assigned to users, including those with privileged access, based on their job classification and function, and the least privileges necessary to perform their responsibilities. |
| • When it came to privileged user IDs, access was kept to a minimum. It was restricted to the least privileges necessary to perform job responsibilities (7.1.2). | • And it’s the same as before. Required privileges must be approved by authorized personnel. It’s all about making sure that the right people have the right access. |
| • Access wasn’t given out willy-nilly. It was assigned based on individual personnel’s job classification and function (7.1.3). | |
| • And lastly, required privileges weren’t just handed out. They were documented and had to be approved by authorized parties (7.1.4). |
| Old Requirement (v3.2.1) - 8.7 | Updated Requirement (v4.0) - 7.2.6 |
|---|---|
| • It wasn’t a free-for-all. In fact, all access, whether by applications, administrators, or any other users, was strictly restricted. | • Now, all user access to query these repositories is restricted. It’s only possible via applications or other programmatic methods, and the access and actions allowed are based on user roles and the principle of least privilege. |
| • But how did users interact with the databases? Well, all user access, queries, and actions on databases were done through programmatic methods. No manual meddling allowed. | • But who can directly access or query these repositories? Only the responsible administrators have that privilege. |
| • And who could directly access or query databases? Only database administrators had that privilege. | The updated requirement also introduces two sub-requirements: • 7.2.6.a: This one’s all about verification. Policies and procedures need to be examined, and personnel interviewed, to make sure that processes are defined for granting user access to query repositories of stored CHD. And this must be in accordance with all elements specified in this requirement. |
| • What about application IDs for database applications? They could only be used by the applications themselves, not by individual users or other non-application processes. It’s all about keeping things secure and orderly. | • 7.2.6.b: This sub-requirement is about checking the configuration settings for querying repositories of stored CHD. These settings need to be examined to verify that they’re in accordance with all elements specified in this requirement. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.3 focused on the development of both internal and external software applications, including web-based administrative access to applications. | In PCI DSS v4.0, Requirement 6.2.1 focuses on secure development of “bespoke and custom software”, replacing the terms “internal and external”. |
| - 6.3.a: Verify that software-development processes align with industry standards/best practices. | - The software should be developed based on industry standards and/or best practices for secure development. |
| - 6.3.b: Ensure information security is integrated throughout the development life cycle. | - The development should be in accordance with PCI DSS (Payment Card Industry Data Security Standard). This includes aspects like secure authentication and logging. |
| - 6.3.c: Confirm that software applications comply with PCI DSS. | - Information security issues should be considered during each stage of the software development lifecycle. |
| - 6.3.d: Interview developers to ensure these processes are implemented. | - The requirement mandates that software development procedures must be documented and examined to ensure that all security considerations are integrated into every stage of the development process. This ensures a clear documentation trail of security practices. |
Conclusion
Having the listed documents in place is essential for organizations to prove that security threats have been addressed and that appropriate security measures have been implemented to mitigate any risks or cyber threats. Further, these documents work as evidence for organizations to provide to auditors for the Compliance Audit. These documents listed here can work as a compliance checklist that can also help organizations put in place the technologies, processes, and people appropriate for achieving, and sustaining compliance while also managing risk.
But, having this list is just about half the work done since organizations will need effective appropriate identification of applicable documentation, identification of the right templates and appropriate expertise to ensure that ground realities and organizational expectations are reflected in the documentation set. Organizations looking for assistance in NCA ECC Compliance and documentation, VISTA InfoSec can be your true partner and guide for achieving your compliance goals. We have been in the Cybersecurity Industry for 16+ years and have the experience, expertise, and knowledge to help organizations like you in your efforts of compliance. For more details about us, or the regulation or the NCA ECC services that we offer, you can visit our website www.vistainfosec.com or drop us a mail at info@vistainfosec.com
Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.
