Naavi.org

ISO 27701 was published on August 6, 2019 as an extension of ISO 27001:2013. It was a framework for management of Privacy of Personal data and included requirements for Privacy Risk Assessment, Privacy Impact Assessment, Data Protection Impact assessment and Privacy by Design.

It identifies PII controllers and PII processors as two categories of organizations which process Personal Information and PIMS (Personal Information management System) as a System within an ISMS system.

For certification purpose, only ISO 27001 is considered the Certification standard and ISO 27701 is considered a guidance document. Hence for any organization whose PIMS needs to be certified under ISO 27701, they need to be also compliant with ISO 27001 and certified for “ISO 27001 with extension of ISO 27701”.

ISO 27001:2022 is itself considered a “Privacy” related standard and under Annex A 5.34 states ” The organization shall identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements”. Hence ISO 27001:2022 certification requires a consideration of the applicable law and its requirements. Hence ISO 27701 can only be a guidance. But it would be more appropriate if a new version of ISO 27701:2019 is released since the current version to which it is mapped is ISO 27001:2013.

Before ISO 27701 was published there was already another privacy standard ISO 29100 (2011) and also ISO 27018 (2014/2019). ISO 29100 is a framework that defines basic privacy terminology, defines roles of different organizations and contains a list of 11 Privacy principles. ISO 27701 makes a normative reference to ISO 29100. ISO 27018 is a PIMS framework and applicable only for PII processors. We can now consider ISO 27701 as a more comprehensive PIMS framework and applicable for both PII controllers and PII processors.

Additional PIMS requirements that ISO 27701:2013 requires as an extension of ISO 27001 are as follows:

Under Clause 5 the ISO 27701 provides PIMS specific requirements appropriate to an organization acting either as a PII Controller or a PII processor.

Clause 6 gives the PIMS specific guidance acting as either a PII Controller or PII Processor.

Clause 7 and 8 gives additional ISO 27002 guidance for PII Controller and Processor respectively.

In ISO 27002, PIMS specific guidance is found in clauses 5,6,7,8,9,10,11,12,13,14,15,16 and 18.

The additional control objectives and controls introduced for a PII Controller in the annexe 7.2 are to determine and document that processing is lawful, with legal basis as per applicable jurisdictions and with clearly defined and legitimate purposes.

Under this control guidance is provided through sub controls for determining the legal basis, obtaining consent, conduct of privacy impact assessment, security of PII etc.

Clause A.7.3 is the next additional control with the objective to ensure that the PII principals are provided with appropriate information about the processing of the PII and to meet any other applicable obligations to PII principals related to the processing of their PII.

Under this Controls for protecting the rights of PII principals such as providing information , right to withdraw consent, right to erasure etc.

Clause 7.4 addresses the objective of ensuring that the processes and systems are desgned such that the collection and processing are limited to what is necessary for the identified purpose, by default.

Clause 7.5 addresses PII sharing, transfer and disclosure which includes cross border transfer requirements.

Table B provides similar guidelines applicable to Data Processors.

Thus ISO 27701 extends ISO 27001 to cover controls identified with Privacy protection as per laws such as GDPR. The annexures also provide mapping with different aspects of GDPR.

Though ISO 27701 does not directly address the needs of the Indian requirement like what PDP CMS does, since the principles of privacy covered in the ISO 27701 are similar to any other data protection laws, ISO 27701 can be used along with ISO 27001 for an ISMS-PIMS establishment along with a well constructed Statement of Applicability.

A Russian ransomware gang CLOp has reportedly been exploiting a zero day vulnerability in a secure file transfer software called MOVEit and has reportedly affected hundreds of businesses in UK and USA.

Moveit is a managed file transfer software product produced by Ipswitch,inc which encrypts files and uses FTP or SFTP protocols to transfer data. According to wikipedia, a stable release of the software is dated 2019. The program is used by many organizations including PWC, E& Y, BBC, Shell, British Airways, Boots, Zellis and several government agencies such as U.S. Department of Energy, the Louisiana Office of Motor Vehicles, the Oregon Department of Transportation, the Minnesota Department of Education, the Novia Scotia government etc.

It is surprising that the vulnerability remained undetected and unpatched showing the lack of security oversight in the software product industry worldwide. Though thousands of high profile companies used the software, it is surprising that no audit had brought out the security vulnerability.

The attack has rightly renewed the call for holding the software developers legally responsible for lack of “Reasonable Security”. Under the Indian law, if the software supplier contract is a “Service Contract”, the software company may be liable as an “Intermediary”.

If it is an outright sale, then the software developer may claim transfer of responsibility on the basis of “As is Where Is” sale contract. However reasonable disclosure of the product vulnerabilities or alternatively an access to code audit is essential for the software supplier to escape full liability as an “Intermediary” under ITA 2000.

Naavi has always advocated such a liability and as a measure of better security and it appears that Whitehouse’s National CyberSecurity Strategy has also called for similar measures.

Speaking on behalf of the software developers, Naavi has advocated that apart from the reasonable efforts at testing before a “Stable Release”, every developer should mandatorily run a “Bug Bounty Program” and try to continue the testing in the public space with a reward program implemented fairly. This is a compliance measure included in the now increasingly appreciated PDPCSI (Personal Data Protection Compliance Standard of India), a framework of compliance designed by Naavi and implemented by FDPPI in its certification audits.

We may also highlight that this software MOVEit may be classified as an “Automated Personal Data Processing Software” and hence use of the software was subject to regulations like GDPR. Compliance in such context required a DPIA by the user organization and a requirement of an assurance certificate from the licensing organization.

It is now the turn of GDPR supervisory authorities to question the users of MOVEit and demand payment of penalties for not conducting DPIA when they started using the software.

According to securityweek.com the company has now started releasing security patches which will apply necessary changes to Moveit transfer and Moveit Automation, the two products affected by the vulnerability.

One of the vulnerability patched is a SQL injection vulnerability that allows an unauthenticated attacker to gain unauthorized access to the MOVEit Transfer database. Using this vulnerability, an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.

The patches also covered multiple high-severity Progress MOVEit Transfer vulnerabilities that allowed authenticated attackers to gain unauthorized access to the MOVEit Transfer database. where by an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.

Security investigators in KROLL have reported details of the codes exploited by the hackers and indicate that over the course of approximately 14 minutes, threat actors were observed exploiting a MOVEIt web server, dropping a web shell, establishing connections to the web shell, and initiating automated data enumeration and exfiltration preparatory steps. They also noted that there were no active user sessions created in the table, no log entries and no unusual activity appearing within the MOVEit logs. At the end of the 14 minutes, a new threat actor IP address established a web shell connection and what followed for the next several hours were several thousand GET and POST requests which, when overlayed with the available firewall logging, indicated several large volumes of data being transferred to the new IP address.

Kroll observes that because of the exfiltration method used, it can be missed during initial forensic investigation. However the organizations need to carefully observe the GET and POST requests executed and if any uptick is observed, additional measures triggered to confirm the malicious activity.

The lessons that Privacy professionals should take from the incident are

a) Document an assurance from all software suppliers that they have undertaken reasonable measures of testing and the installed version is free from zero day vulnerabilities.

b) Conduct and document a DPIA when new software products/services are used

c) Initiate a “Exfiltration Watch” which observes any accelerated activity and raise alarms as a part of the Data Leak Prevention strategies.

Software developers need to revise their testing process to stand the test to be called “Reasonably rigorous” and support by continued bug bounty program”.

Buyers of software need to review the contracts to see if they have a Code review option or an indemnity against zero day vulnerabilities or at least an insurance back up.

Naavi

Comments welcome

Also Refer:

Bug Bounty Policy as part of Corporate Governance Responsibilities

various articles at naavi.org

More details on the attack

In the series of articles so far, we have discussed the Scope of ISMS under ISO 27001 as well as the Leadership requirements and some aspects of Planning.

In this article let us list out all the requirements specified under Clause 6 of the standard documentation related to “Planning”.

Under this clause, the document specifies

6.1: Actions to address risks and opportunities

6.2: Information Security objectives and planning to achieve them

6.3: Planning of changes

Under 6.1, the organization shall make an assessment of the risk, establish a risk acceptance criteria, how the risks can be addressed. Planning should also cover actions required for continual improvement and also address “Opportunities”. The mention of “opportunities” indicates that we need to plan with a “Risk-Reward” perspective so that implementation of ISMS does not adversely conflict with the business development. For treating the risk, efforts shall be made to make use of the controls suggested in Annexe A. Apart from detailed planning with responsibility assignment, resources etc, the ISMS needs to recognize the possibility of changes and how they are to be handled.

In providing “Support” for the planned activities, it is necessary to ensure that the organization shall determine the competence of the people assigned with specific roles and retain appropriate documented information as evidence of competence. It is also necessary to build appropriate awareness across the organization with appropriate internal and external communication policies. The activities shall be properly documented and updated and an appropriate document control system shall be adopted so that reference would be facilitated.

Under clause 8 on “Operation”, the standard document requires an operational planning and control system to be developed including the schedule for periodical changes.

It is interesting to note that clause 9 of the standard speaks about the need for measuring the effectiveness of the ISMS implementation. Most of the time this is ignored in implementation since there is no clear template for the same.

In this context we may appreciate that PDPCSI specifies the Data Trust Score (DTS) system and FDPPI has developed a specific suggested mechanism for evaluating the maturity of PDPCMS through a DTS number. A similar approach can be extended to the ISMS also if the DPCMS is used as a framework.

ISO 27001:2022 also requires an established internal audit programme as well as a management review and corrective action.

Lastly the standard document specifies that the ISMS must focus on “Continual Improvement” .

The 10 clauses of the standard document are supported by the 93 controls in the Annexe A, which has been drawn from ISO 27002 which needs to be referred for detailed explanation of any of the Annexe items.

We shall try to review these 93 control items in subsequent articles.

Naavi

We are presenting a series of articles in this series to spread the awareness and understanding of ISO 27001, ISO 27701 and PDPCSI.

ISO 27001 is a certifiable standard while ISO 27701 is a requirement which can be certified only along with ISO 27001. ISO 27001 refers to ISMS where as ISO 27701 refers to PIMS.

On the other hand, PDPCSI (Personal Data Protection Compliance Standard of India) is a framework for Personal Data Protection by organizations in India in compliance with the legal standards such as Information Technology Act 2000/8 and the upcoming DPDPB 2023. PDPCSI refers to PDPCMS which is the personal data protection compliance management system.

Since PDPCMS/PDPCSI is focussed only on personal data, it compares directly with ISO 27701 instead of ISO 27001. However, since ISO 27701 cannot be implemented without ISO 27001 which is a foundation standard, an understanding of ISO 27001 will help us understand PDPCSI better. Also ISO 27001 is relevant for the preservation of CIA of personal data within PDPCSI where Model Implementation Specifications (MIS) 31-50 address different aspects of security under the CIA concept. Hence there is some comparison between PDPCSI and ISO 27001 which may be relevant.

Readers may kindly appreciate the context in which this series of articles have been presented and read all articles in the series besides information available on PDPCSI.

In this article let us continue our discussion on ISO 27001 and discuss the recommended Governance Structure to meet the objectives of ISO 27001:2022.

Clause 5 of ISO 27001 on leadership lists out the following requirements as “demonstration of leadership and Commitment” of an organization.

a) ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization;

b) ensuring the integration of the information security management system requirements into the organization’s processes;

c) ensuring that the resources needed for the information security management system are available;

d) communicating the importance of effective information security management and of conforming to the information security management system requirements;

e) ensuring that the information security management system achieves its intended outcome(s);

f) directing and supporting persons to contribute to the effectiveness of the information security management system;

g) promoting continual improvement; and

h) supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility.

Under Clause 5.3, the standard prescribes that

Top management shall assign the responsibility and authority for:

a) ensuring that the information security management system conforms to the requirements of this document;

b) reporting on the performance of the information security management system to top management.

We can interpret the above requirements as projecting a need of a designated Information Security Manager (ISM) or Chief Information Security Officer (CISO) so that there is accountability for implementation and reporting to the top management.

Even ISO 27701 does not clearly specify the need of a DPO which is mandatory in many laws for certain category of implementers.

Under PDPCSI which requires compliance of law directly, it is essential to define the role of the implementing organization and the mandatory need for a designated role of a Data Protection Officer. It suggests the three levels of governance Governance Committee, DPO and Process Level Data Controllers besides a “Privacy Officer” in a large organization.

As a recommendation, most experienced auditors recommend that under ISO 27001 there shall be a “CISO” or “ISM” who will be responsible for implementation and monitoring as well as internal audit. It is common for organizations to use the assistance of external consultants when ISO 27001 is implemented for the first time and also get Certified by an independent auditor. Maintenance is done by the CISO and the certification audit is renewed from time to time normally after 3 years.

Naavi suggests that the Governance system

1. A Governance Committee (Steering Committee) to provide overall guidance
2. CISO to be the designated person responsible for coordinating the entire activity
3. Support team which can be called the IS organization.

Though not specified by most ISO auditors, Naavi suggests that it is necessary to identify the following support roles.

a) Data Custodians for each data store

b) Controllers who monitor incoming data and data disclosures

c) Controllers who monitor the different data transformation processes within the organization.

If an organization has multiple locations and business divisions, it would be better if Information Security Champions are identified at each of the divisions and the locations to assist the CISO as a central coordinator.

The Steering committee will have representation of all stake holders within the organization and will ensure that there is cooperation of all stakeholders in the implementation on a continuing basis.

The organization should not project ISMS as the responsibility of only the IT department since it is more an organizational responsibility than the IT responsibility. The “Security Culture” should pervade the entire organization.

Some of these suggestions cannot be directly indicated in a framework document and has to suggested by experienced consultants.

We shall discuss the Annex A controls individually which provides the high level indication of what is expected as a “Control” within which we shall draw inferences on not only the suggested Governance Structure but on other aspects as well.

Naavi

In the previous article we discussed the need for creating Asset Inventory as part of the Context setting.

In the process, we identified four different aspects such as “Data Storage Points”, “Data Collection Points”, Data Processing Points” and “Data Disclosure Points” to be identified in a network to create the Asset inventory. We also discussed the concept of “Data Valuation”. We did not stop at looking at Data Value from the abstract concept of “Everything that assists the business has a value” but went on to underscore the need for assigning the rupee value of the asset that can be brought into the balance sheet if need be.

If we want the CFO to sanction a budget for ISMS, then he has to be convinced that there is an X crores worth of data that needs to be protected and the ISMS will mitigate the risk of loss or erosion of this X Crore asset value. For this purpose assessing the rupee value of the asset is important and Naavi’s DVSI (Data Value Standard of India) tries to suggest some methodology for the purpose particularly for the Personal data.

In the context of ISO 27001, the valuation in rupee terms is relevant since if there is a ransomware attack, the hacker would ask for a ransom based on his estimated value of the data. His valuation of data may either be based on the market value for the data in the Dark Web or the amount upto which the organization would pay to protect its reputation damage or save on cost of reconstruction of data. For the organization therefore “Opportunity Cost” and ” potential damage” is a measure of value. For the hacker the “Realisable market value” is a measure of its value.

If the ISMS manager wants to assign a value it may depend on the nature of the activity of the organization. If Data is a raw material in the business of the Company and gets converted into finished goods at the end of a process (Eg Data Analytics Company) then the value can be computed on the basis of the accumulated cost from generation of the data to its current status in the life cycle moderated by revaluation based on the market value. If data is only a tool of business, its value is based on the cost of creation only.

Whatever be the methodology used for valuation and whether it is only an approximation for the purpose of a “Note to the Accounts” or to be incorporated in the balance sheet as a “Contra Item”, there is a need to first classify the information into different value buckets.

In the ISMS context, data classification is based on the “Risk Potential” and hence it is common to observe a classification as “Confidential”, “Restricted”, “Internal” and “Public”.

Some examples of classification on this basis are

• Confidential: This level of classification applies to information that could cause serious harm to the organization if it were disclosed to unauthorized individuals. Examples of confidential information include trade secrets, financial data, and customer information.
• Restricted: This level of classification applies to information that could cause some harm to the organization if it were disclosed to unauthorized individuals. Examples of restricted information include employee records, marketing plans, and product development information.
• Internal: This level of classification applies to information that is not confidential or restricted, but that should not be disclosed to the public. Examples of internal information include employee training materials, meeting minutes, and financial reports.
• Public: This level of classification applies to information that is not confidential, restricted, or internal. Examples of public information include press releases, product brochures, and website content.

On the other hand, a PII classification has to be done under scales based on the “Sensitivity” . For examples as against a general categorization of “Personal Data”, one can create a category “Sensitive Personal Data” or “Critical Personal Data” based on different risk profiles of the data itself.

Hence Data has to be first classified as “Personal” and “Non Personal”, and then Non Personal Data should be classified based on the Confidential, Restricted, Internal and Public criteria and Personal data classified as is relevant for the applicable law.

PDPCSI or any other Privacy frameworks therefore use a classification different from the ISO 27001. PDPCSI goes a step further than other frameworks since it recommends sensitivity based classification on whether the data belongs to the Employees or others, Minors or Adults , Deceased individuals or Living Individuals etc.

The classification suggested under A 5.12 of ISO 27001 states….

“Information shall be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.”

ISO 27701:2019 refers to EU GDPR in its introductory reference but does not provide clear guidelines within the document. Hence classification based on GDPR will drive ISO 27701.

On the other hand, PDPCSI pitches the classification requirement to be “Compliance Based” and states as follows

“The organization shall classify  data based on nature of personal data, its sensitivity, type of data subject, whether   minor data or employee data is involved,   the country of origin, etc”

Thus the Context setting includes creation of a data inventory along with the classification.

Apart from creating an “Inventory of Data” where it lies in storage, it is also necessary to identify the “Process Inventory” which lists all the processes where the input data and output data is different. The modification of data that occurs within a process is to be captured for risk assessment (eg Automated Decision making risks). This will also assist in designating “Process Controllers”, “Consent Controllers”, “Disclosure Regulators” and “Data Custodians” who are all different organs of the ISMS Manager.

To further take control of the Data inventory, it is necessary to identify the Data Input points and Data Disclosure points so that the Inventory of data in storage and data in process can be managed from the point of view of CIA principles. Data Disclosure in this context is mainly to the external parties since internal data disclosure gets merged with transfer of data from one process to another as an input data into the next process.

To summarize, after setting the context for ISMS, we should have a proper understanding of the classified data based on an acceptable criteria. We should know where the data is stored, where all they are processed, which are the input and exit points to be secured.

In the Planning stage these are important steps that needs to be completed before we go further into the creation of the ISMS Governance structure. Then we go into creation of policy documents, then to implementation of controls, then to review and correction. These are the steps that ISMS has to go through .

(To Be Continued)

Naavi

Before an organization sets about to establish an ISMS or an auditor starts an ISO 27001 audit, it is essential to understand and set the ‘Context’ in which the activity needs to be planned and implemented.

By ‘Context’ we mean the internal and external issues that reflect the constraints for the activity of the organization.

To the extent these constraints are manageable, they can be addressed as part of the suggested business policy changes that can accompany the setting up of the ISMS. To the extent the constraints are internal and affect the ISMS risks, they need to be mitigated as a part of the risk management policy. To the extent the constraints are not controllable, they need to be accepted and risks arising thereof become absorbed risks.

Most of the time the role of an auditor arises in an existing organization which already has established a vision and mission and has a top management Governance system tuned to business objectives. The IS objectives are to be integrated into this structure. In the process it may cause disruptions of existing systems and hierarchy of decision making which has to be recognized as an “Implementation Risk” and has to be handled with finesse.

This is the toughest part of the activity of ISMS and is often addressed as the challenge of getting a Buy-In by the top management. A successful ISMS auditor needs to therefore have the skills of communication and persuasion required to get the plan accepted and resources sanctioned.

Most often, the ISMS activity in an organization is triggered because the market forces dictate them. Some clients would have raised a query “Are you ISO 27001 compliant? or Are you GDPR Compliant?”, or “Are you ITA 2008 Compliant?”, or “Are you DPDPB 2022/23 compliant?” etc.

The marketing person might have given a feedback that they may lose a prospective contract because of not being able to provide an assurance to the client about the status of Information Security/Privacy Protection in their company.

At this time, the Company needs to decide on what is required for them in the given context and chose if they have to go for ISO27001 or DPDPB 2022 or GDPR as a framework of designing its activity.

If a Company is operating in India entirely for the Indian customers, it has more value for ITA 2008 compliance than GDPR certification. If a company is interested in Privacy more than IS, priority has to be for GDPR than ISO 27001. In India ITA 2000/8 today is both an IS law as well as privacy law. The company has to determine this at the time it sets the context.

A GDPR or DPDPB 2022 framework may be recognized as a “Privacy Compliance” requirement and not an ISMS per-se. On the other hand ISO 27001 is an ISMS per-se and when associated with ISO 27701 adds Privacy also. However, a GDPR or DPDPB 2022 does address CIA principles of information security within the “Personal Information” domain and hence ISO 27001 is still relevant for implementation of GDPR or DPDPB. If the same principles are extended to Non Personal Data, a DPDPB compliant organization can be also compliant with ISO 27001 standards as a whole.

When we plan an ISMS under ISO 27001, we need to understand that the context has to take into account that there is a law in India on Information Security called Information Technology Act 2000/8 (ITA 2000/8) and there will be consequences if the ISMS does not meet the requirements of ITA 2000/8. Hence the need to understand the legal environment and ensure that the ISMS is in sync with the ITA 2000/8 is an essential part of the context building.

Available resources of a Company obviously is a constraint which has to be factored into the planning since an SME with a turnover of Rs 10 crores cannot be expected to spend as much money as an MNC with a turnover of Rs 1000 crores. A start up with 20 employees cannot plan an ISMS like an organization with 20000 employees. Hence the ISMS planner/auditor needs to be flexible and this gets reflected in the SOA (Statement of Applicability) or the Implementation Charter (PDPSI specification).

Apart from the legal compulsion which if not complied with, may come with heavy penalties, it is necessary for the management to be convinced about the need for the ISMS or DPCMS (Data Protection Compliance Management System). The best way to achieve this is to present the ISMS requirement as a “Business Objective”. It is for this reason that the ISMS planning has to take into account the needs of the CMO, CFO and the CEO as much as it is an initiative of the CTO to reduce the risk of data breach and meeting the risks of a Cyber attack.

This “Management perspective” of ISMS has to be addressed by linking the ISMS need to the business objective. Unless an organization is a philanthropic organization, management cannot disassociate itself from the profit motive. Hence it will be impractical if we as ISMS planners donot understand the needs of the management to make money for the Company. Hence the views of the CMO/CFO/CEO needs to be adequately respected and their acceptance to any ISMS proposal is a necessity.

Hence it is always better to start the ISMS activity with the development of an Information Asset Inventory and making the management realize the value of the assets they manage and the consequences of not securing these valuable assets. Developing an inventory of Data Assets mean identifying the Data Storage points, Data Collection Points and Data Processing Points. It is better to add the Data Disclosure points also to this “Data Mapping” exercise so that the lifecycle of data in the organization is properly understood for determining the context.

ISO 27001 may not directly refer to any controls that direct them to financially value the information assets while PDPCMS based on PDPCSI does mandate a thought on Data Valuation as a part of brining the visibility of the asset value to the top management. Similarly PDPCMS also takes into account the need for “Monetization” of personal data within the legal permissions by suggesting appropriate policies for “Profiling”, “Monetization” etc.

When a visionary ISO 27001 implementer interprets the “Context” under clause 4, he may include the “Risk Analysis” based on ISO 31000 and may arrive at the same conclusion that PDPCMS arrives at regarding the need for Data Asset Valuation. But as a framework, a majority of the implementers of ISO 27001 may miss these requirements.

It is for these reasons we say that PDPCSI is an improvement over existing frameworks such as ISO 27001 (with ISO 27701 combined).

It may take time for the market to realize this but it will happen over a period of time as PDPCMS becomes more and more common in implementation.

Naavi