CY SYSTEMS Blog

Loading

Archives September 2023

Blog , Compliance , CySYS , DPDP2023

Digital Personal Data Protection Bill 2023 in India: A Comprehensive Guide

The Union Cabinet has given its nod to the Digital Personal Data Protection (DPDP) Bill 2023 draft, which will be introduced in the upcoming monsoon session of Parliament (July 20 to August 11).

The main objective of the bill is to lay down a holistic legal framework that governs the collection, storage, processing, and transfer of personal data by entities, both governmental and private, operating within the boundaries of India.

The bill mandates the payment of fines for non-compliance with requirements such as seeking consent for the processing of data, making it crucial for organizations that handle personal data to understand how it will work.

This blog will tell you everything you need to know about the bill and provide useful steps that will help your organization prepare for its implementation.

Understanding the Key Aspects of the Bill

The DPDP Bill is all about protecting personal data in the digital age. It applies to any data about an individual that can identify them, whether it’s collected online or offline and then digitized. 

The DPDP Bill extends its reach to digital personal data processing that happens outside India, but only if it involves profiling or offering goods/services to individuals within India. In other words, any organization in any part of the world, which handles the personal data of Indian citizens, has to adhere to it.

Now, let’s discuss the responsibilities of those who handle personal data, known as data fiduciaries. First, they must process personal data lawfully and with the consent of the person it belongs to, also known as the data principal. They need to clearly communicate what kind of personal data they collect and for what purposes. And when it comes to children, they must get verifiable consent from their parents. If they don’t follow these rules, they could face penalties.

The DPDP Bill takes data breaches seriously. Both the data fiduciary and any data processor they work with must notify the Data Protection Board and the affected individuals in case of a breach. 

Data principals, the individuals whose personal data is being processed, have certain rights under the DPDP Bill. Some of these rights include:

A) The right to know if their data is being processed

B) The right to know what kind of data is involved

C) The right to know who it’s being shared with

D) The right to request corrections or deletions if the data is no longer necessary

If they’re not satisfied with how their concerns are addressed, they can file a complaint with the Data Protection Board.

Provisions of the Bill

This DPDB Bill 2023 will extend its legal umbrella to cover all online data (and offline data which is digitized) in India, ensuring comprehensive protection for personal information.

The contents of the Bill, the first draft of which was published in July 2018, will only be disclosed after the Parliament session. 

Here is a look at the key highights of the bill based on what we learnt from the previous draft:

Government supervision

A Data Protection Board, established by the Union government, will regulate personal data matters, primarily enforcing compliance and imposing penalties. The government will influence the board’s composition, terms of service, and overall implementation of the law.

Data storage

Unlike previous laws, the draft bill doesn’t require exclusive data storage in India but restricts cross-border data transfer to countries authorized by the Indian government.

Monetary penalties

The draft bill allows only monetary penalties for breaches or non-compliance, ranging from INR 50 crore to INR 250 crore, with a maximum penalty of INR 500 crore for significant data breaches.

Data of minors

Parental consent is mandatory for individuals under 18, although concerns exist about differentiating consent between toddlers and adolescents, the potential impact on personal development, and the violation of the Rights of the Child.

Data collection

Specific limitations on data collection have been removed, allowing data fiduciaries to collect personal data with the consent of the data principal while informing them of the relevant purpose for data collection.

Government exemptions

Government bodies can be exempted from regulations for reasons such as sovereignty, security, foreign relations, and public order, without specific criteria for exemptions.

Limited information requirements

The draft narrows the scope of information provided to data principals, focusing on personal data sought and the purpose of data processing, rather than extensive rights, grievance mechanisms, retention time, and data sources.

Missing provisions

It should be noted that the draft lacks the inclusion of two important provisions:

Data portability

The right to data portability empowers data principals to access and examine their personal data in a structured format. It enables them to choose the platforms on which they want their data to be shared, eliminating the hassle of providing all their personal data again when switching platforms.

Foregone information

The omission of the right to foregone information creates confusion between the general right to erasure and the right to be forgotten, which could potentially undermine freedom of speech and expression for others.

Seven Core Pillars of the Bill

How it will affect Businesses and Organizations

The Data Protection Bill will have significant impacts on businesses and organizations that collect and process the personal data of Indian citizens. Here are some key areas of impact:

Compliance and Legal Obligations

The bill establishes compliance requirements and legal obligations for data-handling entities. Businesses and organizations will need to ensure they adhere to these obligations, such as obtaining consent for data processing, maintaining data accuracy, implementing security measures, and establishing mechanisms for data breach notification. Non-compliance can result in penalties and reputational damage.

Data Governance and Accountability

Robust data governance practices and accountability is a requisite of the bill. Organizations will need to establish policies and procedures for data handling, including data minimization, purpose limitation, and storage limitation. They will also need to appoint Data Protection Officers and demonstrate accountability in their data processing activities.

Consent Management

Obtaining valid consent from individuals for processing their personal data is mandated by the bill. Businesses and organizations will need to review their consent management practices to ensure they meet the bill’s requirements. They will also need to provide clear and transparent information to individuals regarding the purpose and extent of data processing.

Data Localization and Cross-Border Transfers

The bill addresses the issue of data localization, specifying that certain categories of personal data may need to be stored within India. This may impact businesses that operate across borders or rely on international data transfers. They will need to evaluate their data storage and transfer practices to ensure compliance with the bill’s provisions.

Impact on Business Models and Innovation

The bill’s provisions may require businesses and organizations to make changes to their existing business models and data processing practices. It may impact data-driven innovation, as stricter regulations and requirements may introduce additional complexities and limitations on data usage. Organizations will need to assess the impact on their operations and adapt accordingly.

Increased Focus on Data Security 

The enforcement of proper data security and protection is highlighted by the bill. Businesses and organizations will need to implement appropriate technical and organizational measures to safeguard personal data from unauthorized access, breaches, and misuse. They may need to invest in robust cybersecurity infrastructure and regularly review their security practices.

Steps to take in preparation for DPDP Bill implementation

In order to be prepared for the bill’s implementation, organizations can take the following steps.

Conduct a data audit

Start by conducting a comprehensive audit of the personal data your organization collects, processes, and stores. Identify the types of data you handle, the purposes of processing, and the legal basis for processing.

Review and update policies

Review your existing privacy policies, consent mechanisms, and data-handling procedures. Update them to align with the requirements of the data protection bill, including provisions on consent, data minimization, purpose limitation, and data subject rights.

Implement strong data governance 

Establish robust data governance practices within your organization. This includes defining roles and responsibilities for data protection, appointing a Data Protection Officer (if required), and implementing internal policies and procedures to ensure compliance with the bill’s provisions.

Obtain valid consent

Review your consent management processes to ensure they meet the bill’s requirements. Implement mechanisms to obtain valid and informed consent from individuals, clearly explaining the purpose, extent, and duration of data processing. Ensure individuals can easily withdraw consent if they choose to do so.

Enhance data security measures

Strengthen your data security measures to protect personal data from unauthorized access, breaches, and misuse. Implement appropriate technical and organizational safeguards, such as encryption, access controls, regular vulnerability assessments, and employee training on data security best practices.

Develop a data breach response plan

Prepare a comprehensive data breach response plan that outlines the steps to be taken in case of a data breach. This includes timely identification and assessment of breaches, notification procedures for affected individuals and the Data Protection Board, and remedial actions to mitigate harm and prevent future incidents.

Conduct employee training

Educate your employees about the provisions of the data protection bill and their roles and responsibilities in ensuring compliance. Provide regular training sessions on data protection principles, privacy best practices, and the organization’s data-handling policies.

Establish vendor management processes

Review and update contracts with third-party vendors or processors to ensure they comply with the data protection bill’s requirements. Implement robust vendor management processes, including due diligence, contractual safeguards, and periodic assessments of their data protection practices.

Develop data subject rights procedures

Establish procedures for handling data subject rights requests, such as access, correction, erasure, and objection. Ensure these procedures are efficient, transparent, and compliant with the bill’s timelines and requirements.

Stay updated and seek legal advice

Regularly monitor updates and guidance from the Data Protection Board and relevant authorities regarding the interpretation and enforcement of the data protection bill. Consider seeking legal advice to ensure ongoing compliance and to address any specific concerns or questions related to your organization’s operations.

How We can help you

At CySYS, we have extensive experience in assisting companies with compliance across various frameworks. While the DPDP Bill is yet to be passed, we are fully prepared to help you navigate its requirements. Our expertise extends to compliance with GDPR, ISO 27001, SOC 2, and many other frameworks, making us well-equipped to assist you in preparing for the DPDP Bill.

We understand the challenges that come with regulatory compliance, and our aim is to make the process as seamless as possible for you. Whether it’s implementing the necessary security controls or managing your vendors, we will guide you through every step. If you’re seeking the support of experienced professionals to navigate this new framework, feel free to reach out to us. We’re here to help!

Blog , CySYS , Threat Hunting , Threat Intel

Beware of Fake Banker Android Apps: Protecting Your Financial Information

In the digital age, mobile banking has become an integral part of our lives. The convenience of accessing your bank accounts, transferring money, and paying bills from your smartphone has made banking more accessible than ever. However, this convenience comes with its own set of risks, including the presence of fake banker Android apps that can compromise your financial security. In this blog post, we will explore what fake banker Android apps are, how they work, and most importantly, how to protect yourself from falling victim to them.

What Are Fake Banker Android Apps?

Fake banker Android apps are malicious applications designed to impersonate legitimate banking apps. These apps are created by cybercriminals with the intent of stealing your sensitive financial information, such as login credentials, credit card details, and personal identification numbers (PINs). These fake apps often closely mimic the appearance and functionality of real banking apps, making it difficult for users to distinguish between the two.

How Do Fake Banker Android Apps Work?

  1. Impersonation: Cybercriminals typically create counterfeit versions of popular banking apps. These counterfeit apps may have names and icons that closely resemble the real ones, making it easier to deceive users.
  2. Phishing: Once a user installs a fake banker Android app, it often prompts the user to enter their login credentials and other sensitive information. This information is then sent directly to the cybercriminals, who can use it for fraudulent activities.
  3. Keylogging: Some fake banker apps use keyloggers to record every keystroke made on your device. This means that even if you access your bank’s website through a browser, your login information can still be captured.
  4. Overlay Attacks: Fake banker apps may display convincing overlays on top of legitimate banking apps. When you enter your information, it’s captured by the malicious app instead of the real one.
  5. Data Theft: Beyond login credentials, these apps can also access your personal information, contacts, and other sensitive data stored on your device.

Recently we have received a SMShing SMS from JX-REWRDL

Where it consists of a Malicious URL where it leads to download malicious APK file. 7856754rewards.apk de06f6ddf2345607333060fee3896719b767661260c822d8aa64ff69a3c773a0

File Name download: 7856754rewards.apk

File Hash: de06f6ddf2345607333060fee3896719b767661260c822d8aa64ff69a3c773a0

Upon checking with VT VirusTotal – File – de06f6ddf2345607333060fee3896719b767661260c822d8aa64ff69a3c773a0 we came to know that it was a malicious app and 19 security vendors, and no sandboxes flagged this file as malicious.

We tried to contact the owner of the website we did not get any update using WhoIS mail ID.

and we tried to contact with hosting provider.

After Contacting with hosting provider

Finally, after a couple of follow-ups with respective hosting providers they have suspended the respective domain.

Please beware of downloading Android apps from unknown sources.

Here are few inputs to Protect Yourself from Fake Banker Android Apps

  1. Download Apps from Official Sources: Only download banking apps from official sources such as the Google Play Store or the bank’s official website. Avoid third-party app stores or links from suspicious sources.
  2. Check App Reviews and Ratings: Read user reviews and check the app’s ratings before downloading. Legitimate banking apps will have a high number of downloads and positive reviews.
  3. Review App Permissions: Pay attention to the permissions an app requests during installation. If a banking app asks for unnecessary permissions, it could be a red flag.
  4. Keep Your Device Updated: Regularly update your Android operating system and apps. These updates often include security patches that protect against vulnerabilities exploited by fake banker apps.
  5. Install a Mobile Security App: Consider using a reputable mobile security app that can detect and block malicious apps.
  6. Enable Two-Factor Authentication (2FA): Whenever possible, enable 2FA for your banking apps. This adds an extra layer of security and makes it more difficult for cybercriminals to gain access to your accounts.
  7. Educate Yourself: Stay informed about the latest cybersecurity threats and best practices for protecting your financial information. Knowledge is a powerful defense against scams.
Blog , Compliance , CySYS , Threat Intel

Storm-0558 Update

Microsoft’s latest Storm-0558 findings and summarizes the key learnings cloud customers should take away from the incident.

On September 6th, 2023, Microsoft published a follow-up to their initial investigative report from July 11th about Storm-0558 — a threat actor attributed to China who managed to acquire a signing key that allowed them to gain illicit access to Exchange and Outlook accounts. Microsoft should be applauded for the high level of transparency they have shown, and their willingness to share this information with the community. However, we feel that the latest blog post raises as many questions as it answers.

Estimated attack flow leading to MSA signing key capture by Storm-0558

Newly revealed information

The following is a summary of the new information provided in Microsoft’s latest report about how the signing key may have been compromised by the threat actor (see the diagram above for a visual representation of the attack flow as we currently understand it):

  • There is evidence that a Microsoft engineer’s corporate account was compromised by Storm-0558 “[at some point] after April 2021.”, using an access token obtained from a machine infected with malware.
  • This engineer had permission to access a debugging server in Microsoft’s corporate network.
  • This debugging server contained a crash dump that originated in a signing system located in Microsoft’s isolated production network.
  • This crash dump, which was the result of a crash that occurred in April 2021, contained the aforementioned MSA signing key.
  • The inclusion of the signing key in this crash dump was the result of a bug, and a separate bug caused the signing key to remain undetected on the debugging server.
  • Based on the events described above, Microsoft has concluded that the most likely method by which Storm-0558 acquired the MSA signing key was through this compromised account, by accessing the debugging server and exfiltrating the crash dump that contained the key material.

Besides providing the above information about how the key was most likely to have been compromised, Microsoft’s latest report also publicly corroborates our own conclusions (published July 21st) about the contributing factors to this incident, namely:

  1. Prior to the discovery of this threat actor in June 2023, the Azure AD SDK (described in the report as a “library of documentation and helper APIs”) did not include functionality to properly validate an authentication token’s issuer ID. In other words, as we explained in our previous blog post, any application relying solely on the SDK for implementing authentication would have been at risk of accepting tokens signed by the wrong key type.
  2. As mentioned in Microsoft’s original report, Exchange was affected by a vulnerability that caused it to accept Azure AD authentication tokens as valid even though they were signed by an MSA signing key – this vulnerability was ultimately exploited by Storm-0558 to gain access to enterprise accounts. In their latest report, Microsoft clarified that this issue was in fact a result of the missing validation functionality in the SDK: at some point in 2022, the development team in charge of authentication in Exchange incorrectly assumed that the Azure AD SDK performed issuer validation by default. This caused validation to be implemented incorrectly, leading to a vulnerability.

What does this mean?

The timeline that can be deduced from the latest report seems to indicate that due to log retention policies (understandable, given that the activity might have stretched over two years), Microsoft can only partially account for all of this threat actor’s activity within their network between April 2021 and May 2023. Additionally, the report does not explicitly state when the crash dump was transferred to the debugging environment or when the engineer’s account was compromised; only that each of these events occurred sometime after April 2021. If we assume that they both happened at the earliest possible point on the timeline — let’s say May 2021 — then that would mean that the threat actor might have been in possession of the signing key for over two years prior to being discovered in June 2023. Furthermore, while Microsoft have reviewed their logs and definitively identified the use of forged authentication tokens for Exchange and Outlook accounts throughout May 2023, we are nevertheless led to the conclusion that the threat actor might have been forging authentication tokens for other services during this two-year period.

As we explained in our last blog post on the subject, someone in possession of this MSA signing key was not limited to forging authentication tokens for just Exchange and Outlook – they could have forged tokens that would have allowed them to impersonate consumer accounts in any consumer or mixed-audience application, and enterprise accounts in any application that implemented validation incorrectly, such as Exchange. In other words, Storm-0558 was in a position to gain access to a wide range of accounts in applications operated by Microsoft (such as SharePoint) or their customers. As we explained in our previous blog post, this was a very powerful key.

Key takeaways from the key takeaway

Based on what we can learn from Microsoft’s latest report, cloud customers should have the following takeaways from this incident:

  1. Organizations should scan their logs for evidence related to this activity in a time window spanning the period between April 2021 and June 2023 (Microsoft could narrow this window by stating precisely when the engineer’s account was compromised).
  2. Organizations should use a hardware security module (HSM) for key storage whenever possible — this will ensure that key material is never included in crash dumps. As others have noted, the scale at which Microsoft operates might have made this impossible for them to do, but smaller organizations should certainly make it a priority.
  3. As a precautionary defense-in-depth measure, debugging and crash dump data should be purged on a regular basis, since they can contain decrypted information which might be a gold mine for threat actors once they gain access to the environment. In general, sensitive secrets can often be found in unexpected places, such as bash history, hidden image layers, etc.
  4. Additionally, organizations should maintain an inventory of assets in which debugging and crash dump data is collected, stored, or catalogued, and ensure that access controls are in place to limit these assets’ exposure.
  5. Sensitive production environments should be properly isolated from corporate environments which are at higher risk of compromise. While there is no evidence to indicate that the threat actor managed to break through Microsoft’s security boundaries or reach the production environment itself, the root cause here was a failure of data hygiene when transferring potentially sensitive data between the two environments.
  6. Signing keys should be rotated on a regular basis, ideally every few weeks. In this case, the acquired signing key was issued in April 2016 and expired in April 2021, but remained valid until it was finally rotated in July 2023 following Microsoft’s investigation of this incident. This means the key was very long-lived and in use for over 7 years. While Microsoft rotated their signing keys following this incident, at least one (key id -KI3Q9nNR7bRofxmeZoXqbHZGew) appears in both a current key list and in the same list where it appeared in October 2022. If this key remains in use, it should be rotated as well, if only to limit the impact of any (admittedly unlikely) similar potential incident.
  7. Secret scanning mechanisms — particularly those put in place to mitigate the risk of keys leaking from high-to-low trust environments — should be regularly monitored and tested for effectiveness.
  8. Defaults are powerful, and documentation alone isn’t good enough for shaping developer behavior. SDKs should either implement critical functionality by default, or warn users if and when they’ve missed a vital implementation step that must be performed manually. If developers at Microsoft misunderstood their own documentation and made this critical mistake, it stands to reason that any one of their customers might have done the same.

Unanswered questions

Although Microsoft’s report answers some of the burning questions related to this case, there remain several unanswered questions:

  1. Was this, in fact, how Storm-0558 acquired the signing key? Microsoft have stated that their investigation has concluded, meaning that they have exhausted all evidence available to them. Therefore, we will probably never have a definitive answer to this question.
  2. How likely is it that other signing keys that were valid during the two-year period were compromised in the same way? Is there evidence to the contrary? (This would obviously be very hard to prove.)
  3. When exactly was the engineer’s account compromised? Most importantly, what is the earliest possible point in time at which Storm-0558 could have acquired the signing key?
  4. Was the threat actor targeting this engineer specifically because of their access to the debugging environment, or did they have other goals in mind?
  5. Was the engineer’s account and the machine infected with malware the only known compromised entities within Microsoft’s corporate environment during this period? Did the investigation identify other compromised users or systems? When (and how) did the attacker establish their initial foothold in the environment?
  6. When Microsoft says that they haven’t observed the threat actor targeting the users of any applications other than Exchange and Outlook, does this mean that they have definitively proven that the threat actor did not forge access tokens for other services? In other words, do they actually have the necessary logs (going back far enough in time and containing the required data) to reasonably verify this?
  7. At what point did the threat actor identify the vulnerability in Exchange that allowed them to use forged authentication tokens signed by an MSA signing key to impersonate AAD users? Could they have somehow discovered it independently of acquiring the signing key? Might they have discovered the same vulnerability affecting other applications before Exchange became vulnerable in 2022?

Regarding the last question about how the threat actor might have discovered the issuer ID validation vulnerability in Exchange, we can posit a theory that they initially realized that the SDK (which is open source) did not include endpoint validation by default, and correctly assumed that at least some of the SDK’s users — including Microsoft developers — would therefore fail to correctly implement this validation.