UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 6.2 Free with a free account
How Large-Scale Data Storage and Processing Create New Targets for Cyber Attackers
Ethics in Technology · Chapter 6: When Big Data Becomes a Big Risk: Security Gaps, Legal Frameworks, and National DefenseSection 6.2 · lesson 23 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Domestic Laws and Regulations That Govern Data Protection in the United States →← Why Collecting and Analyzing Massive Amounts of Data Raises Serious Privacy QuestionsNext lesson: Domestic Laws and Regulations That Govern Data Protection in the United States →
In this lesson
Aggregation, distributed systems, insider access, and layered controls.
- Explain why scale and combination increase exposure
- Identify data-lake and distributed-system weak points
- Limit access throughout role changes and departure
- Compare protection methods for sensitive fields
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,879 words). Read along, or search it.
Chapter 6
Securing Large Data Platforms
Large data platforms support valuable analysis, while making information security failures potentially far more damaging. The problem includes the number of records, their sensitivity, and the connections between different sources. This lesson examines aggregation risk, distributed infrastructure, insider access, and controls across the data's life cycle. A useful system must let people work, while maintaining boundaries around what they can access. Those boundaries can weaken through insecure settings, stolen accounts, or permissions left behind after role changes. Data lakes add flexibility, but their raw contents may be poorly understood without discovery and classification. We compare masking, tokenization, and generalization, using the source's illustrative customer record. Each technique reduces particular exposure, while retaining limits that must be considered in the actual setting. Historical breaches illustrate the consequences, without claiming that every large platform is equally vulnerable. No single control completes the job, because storage, processing, sharing, and recovery create different responsibilities. The aim is useful analysis with managed access, appropriate information detail, and layered protection.
A Valuable Target
Scale Can Magnify the Consequences of Compromise
Volume can magnify a breach, because one successful intrusion may expose many records at once. Variety can make those records more revealing, when identities, purchases, locations, and relationships are combined. Velocity requires attention to continuing flows, including the connections through which new records arrive. Long retention can expose years of history, rather than only the most recent activity. Many users increase the number of accounts, processes, and privileges that require effective management. The source cites Yahoo's two thousand thirteen theft, as a historical illustration of scale. Later assessment described all three billion accounts then existing, as affected by that theft. Accounts do not mean distinct people, because one person can have more than one account. Large size alone does not determine safety, and smaller systems can also hold highly sensitive information. Architecture, configuration, permissions, and response capability, all shape the actual likelihood and consequences of compromise. Security planning should assess that whole setting, rather than assuming that size or reputation guarantees protection.
Aggregation Risk
Joined Information Can Reveal More Than Its Parts
Aggregation risk concerns the added exposure, when separate sources create a much richer combined picture. A retailer's purchase record describes one activity, while a fitness route describes a different activity. Communication records may reveal relationships, without separately showing the person's complete daily routine. Together, those sources can support inferences, about places, habits, relationships, or sensitive circumstances. An inference is not guaranteed to be correct, but it may still influence harmful decisions. Combining sources can also create identifying patterns that were harder to recognize in each separate dataset. The protection needed for the joined result, should reflect its combined sensitivity. Do not assume that a low-risk source, will remain equally low-risk after every possible join. Define the analytical purpose first, and ask whether the combination is necessary to answer it. Sometimes the safer decision is to avoid a join that provides little justified value. Aggregation should be an accountable choice, rather than an automatic consequence of having access to several datasets.
Identification Risk
Codes and Missing Names Do Not Remove Every Clue
Removing names does not remove every clue that might connect a record with its subject. ZIP code, birth date, and sex illustrate quasi-identifiers, whose combination can be distinctive. Sweeney's two thousand publication estimated eighty-seven percent uniqueness, using historical United States census information. That number describes a historical setting, rather than today's universal rate of successful identification. A suitable external source may supply names, alongside the same remaining characteristics. Linkage can then associate an apparently anonymous record, with a person whose characteristics match. The result depends on population, detail, outside information, and the protections around the release. Replacing names with codes may preserve analytical usefulness, while leaving behavioral or demographic linkage possible. Broader categories can reduce distinguishing detail, when exact values are unnecessary for the task. Restricted access and appropriate release design also matter, alongside the chosen field-protection technique. Assess the complete information setting, before describing a dataset as safely anonymous.
Distributed Platforms
Many Nodes Create More Boundaries to Protect
A distributed platform divides storage or processing across computers that participate as nodes. Large workloads may involve replicated records, parallel tasks, and exchanges between machines. Every relevant connection and node introduces, another boundary that must be configured and protected. Hadoop, Spark, and some NoSQL systems, support this kind of distributed work. A data lake preserves varied raw material for later exploration and analytical use. A warehouse typically emphasizes prepared structures, shared definitions, and consistent reporting records. These descriptions express organizing patterns, rather than rigid limits on every modern product. The lake's flexibility can leave sensitive contents poorly understood, without classification and responsible management. The warehouse's prepared records still need security, rather than becoming safe simply because they are organized. Both require a clear inventory, permissions, and protection suited to their data and actual deployment. Focus on implemented controls and information boundaries, rather than relying on the architecture's label.
Common Weak Points
Protect Ingestion, Nodes, Access, and Administration
The source identifies weak points, at ingestion, individual nodes, user access, and administrative interfaces. Unclassified ingestion can introduce sensitive information that no responsible owner realizes the platform contains. Weak settings and unprotected exchanges can expose, data moving between participating machines. Broad user permissions can give access to fields or exports unnecessary for the present task. Exposed management interfaces can weaken, the boundary around administration of the platform. Defensive responses include discovery, secure baselines, segmentation, authentication, encryption, and restricted administrative access. The source's historical MongoDB example concerns exposed databases, affected by deletion and ransom demands in two thousand seventeen. A ransom note does not prove that an attacker holds a recoverable copy of the deleted records. The teaching point is insecure exposure, rather than instructions for finding or attacking a database. Security features must be checked in the deployed configuration, because availability does not mean they are enabled. Trusted-network assumptions and default settings need review, as the system and its boundaries change.
Insider Exposure
Access Can Be Misused, Mistaken, or Stolen
Insider exposure includes deliberate misuse, accidental disclosure, and accounts compromised by an outside attacker. A malicious person may export information beyond the purpose for which access was authorized. A careless person may expose records unintentionally, despite having legitimate access for ordinary work. A stolen identity can give an attacker, the same broad rights already held by the account. The source cites Tesla's two thousand twenty-three incident, involving confidential information shared outside the organization. A breach notice reported seventy-five thousand seven hundred thirty-five affected people, including employee-related records. The company's notice attributed the misappropriation to two former employees acting against its policies. That historical account illustrates insider exposure, rather than proving every internal account is untrustworthy. Analytical work needs useful access, but not every user requires all records and fields. Export authority may need an additional boundary beyond permission to inspect information within a controlled environment. Authorization should follow the task, and remain subject to review as work and responsibility change.
Privilege Creep
A Role Change Must Also Remove Unneeded Rights
Privilege creep occurs when new responsibilities add permissions, while old responsibilities leave their access behind. Someone can gradually hold far more access, than the current job or task actually requires. Least privilege restricts permissions to the minimum necessary for authorized present work. Role-based access groups permissions by responsibility, while requiring maintained role definitions and membership. It does not automatically remove every stale exception, service credential, or old entitlement. Access reviews confirm continuing need, and provide a process for correcting what is no longer justified. Separation of duties can distinguish sensitive access from the authority to approve an export. Just-in-time elevation allows extra privileges for an approved task and limited period. Monitoring can flag unusual activity, while investigation distinguishes suspicious behavior from a legitimate explanation. Prompt offboarding revokes continuing access, including relevant credentials and channels beyond the ordinary user account. Verify that changes actually take effect, rather than assuming the written policy has changed every permission.
Layered Controls
Protection Follows the Data Through Its Life Cycle
Controls should follow information from arrival through storage, processing, and authorized release. Discovery and classification establish which sensitive information exists and where it is held. Encryption protects data at rest and in transit, when implemented with suitable key protection. It does not prevent misuse after authorized decryption, or automatically secure a compromised endpoint. Authentication checks user and machine identities, while authorization limits what those identities may do. Fine-grained controls can restrict particular tables, rows, columns, or operations according to need. Protected fields and approved exports reduce exposure, when analytical results leave the platform. Minimization and retention limit unnecessary collection, and the duration for which sensitive history remains available. Logging and auditing support review, when records are collected, preserved, and examined appropriately. Protected backups support recovery, but their restoration and separation from the main system need testing. These layers support each other, because no single tool covers every point in the data's life cycle.
Worked Record
Masking Hides Parts; Tokenization Replaces Values
The source uses Maria Lopez's fictional record to compare protection of identifying fields. The original includes a name, ZIP code, birth date, sex, and an order total. Masking hides parts of the name and ZIP code, while leaving some visible information. It also preserves the birth year, rather than retaining the full displayed date. The order total and sex remain unchanged in this illustrative masking example. Tokenization substitutes opaque tokens for the name, ZIP code, and date fields. In the source's example, a separate protected system keeps, the mapping needed to restore original values. That mapping becomes sensitive information, requiring tightly controlled access and appropriate custody. A repeated token can also support linkage, even when its original value is not visible. Other unchanged fields may still reveal something, about the person or a small matching group. Choose the method according to the analytical purpose, rather than treating replacement as absolute anonymity.
Generalization
Preserve the Needed Group, Reduce Unneeded Precision
Generalization replaces exact values with broader categories, preserving information at a less precise level. The source removes the name, and uses a broader region instead of the complete ZIP code. The birth date becomes a range from nineteen ninety-five through nineteen ninety-nine. The order total becomes a range from two hundred to two hundred fifty dollars. Sex remains unchanged in the example, showing that not every field is necessarily transformed. Those changes reduce distinguishing detail, while preserving some information for group-level analysis. An analyst studying regional spending by age group, may not need names or exact birth dates. Less precise fields can therefore serve the purpose, while reducing unnecessary exposure of individual records. Generalization can still leave unusual combinations, so it does not guarantee that every person blends into a large group. Assess remaining uniqueness, available outside information, and how the result is released. The best choice balances the justified analytical need, with protection appropriate to the people represented.
Review
Choose Useful Data and Maintain Its Boundaries
Begin with the purpose, asking why the sources need to be combined for this task. Assess the joined result's sensitivity, rather than relying on separate descriptions of its original components. Identify who needs access now, including specific fields, records, operations, and export authority. Review changes in roles, source contents, interfaces, and the duration of retained history. Check whether remaining detail and outside information, could reconnect the result with an individual. Use classification, secure configuration, authentication, and authorization, as complementary controls rather than competing substitutes. Protection of fields, monitoring, retention, and recovery, address other parts of the same information life cycle. The source's ninety-day location-retention example is illustrative, rather than a universal rule for every organization. Retention should follow the justified purpose, and applicable obligations in the actual setting. Verify that controls remain effective, as the platform, people, and information change over time. Useful analysis and managed boundaries belong together, because large datasets require continuing responsible custody.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About How Large-Scale Data Storage and Processing Create New Targets for Cyber Attackers
What is aggregation risk in big data security?
What is the difference between data masking, tokenization, and generalization?
What is privilege creep and how can it be prevented?
What are some major breaches involving large data platforms?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →