UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 12.7 Free with a free account
The Weak Points in Systems and Human Behavior That Criminals Exploit Most Often
Ethics in Technology · Chapter 12: Cyber Harassment, Cybercrime, and How Digital Criminals OperateSection 12.7 · lesson 73 of 11614 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: How Businesses Become Targets: Financial Fraud, Data Theft, and Corporate Espionage →← What Counts as a Crime When It Happens Through Computers and Digital NetworksNext lesson: How Businesses Become Targets: Financial Fraud, Data Theft, and Corporate Espionage →
In this lesson
Understand the weakness, assess the risk, and close the right exposure window.
- Distinguish vulnerability, threat, exploit, and risk.
- Compare unpatched software, zero-days, misconfiguration, and weak credentials.
- Use CVE identifiers and CVSS severity as inputs to fix priorities.
- Trace the lifecycle and explain why available fixes can remain unapplied.
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,706 words). Read along, or search it.
Cyber Harassment, Cybercrime, and How Digital Criminals Operate
Weak Points Criminals Exploit
A criminal attack often depends on an ordinary weakness in software, settings, or credentials. We will distinguish that weakness from the attack method and the resulting risk. A vulnerability is the weakness; an exploit takes advantage of it. Risk considers both the likelihood of harm and its potential impact. Four categories organize the lesson: unpatched software, zero-days, misconfiguration, and default or weak credentials. They differ, although one system can suffer from several at once. Historical examples include Equifax, Microsoft Exchange, Capital One, and the Mirai botnet. We will also explain CVE identifiers and CVSS severity scores. Those tools inform priorities, alongside actual exposure, known exploitation, and the importance of affected systems. Finally, we will trace the vulnerability lifecycle and distinguish two exposure windows. The goal is to choose the right control and verify that it reaches the affected system.
Core Concepts
A Weakness, an Attack Method, and a Risk Are Different Things
A vulnerability is a weakness that can enable unauthorized access, disruption, or another harmful outcome. It may originate in code, configuration, credentials, or a missing control. An exploit is a tool or technique that takes advantage of that weakness. A threat is a potentially harmful circumstance or event. For malicious activity, a threat actor may be an individual, group, or automated system. Risk combines the likelihood of an adverse event with its potential impact. Consider a hypothetical web service with a known unpatched flaw. The flaw is the vulnerability, while a method triggering it is the exploit. Internet exposure, attempted attacks, effective controls, and sensitive information affect the actual risk. This lesson focuses on malicious exploitation, but incidents can also involve mistakes, failures, or other harmful events. A weakness still matters even when no intentional attacker has yet exploited it.
Four Categories
Match the Type of Weakness to the Appropriate Control
Unpatched software has a relevant fix available, but the affected system does not have it installed. A zero-day is exploited before a relevant fix is available. Misconfiguration concerns inappropriate settings or permissions, rather than necessarily a defect in the underlying code. Default or weak credentials concern logins that provide inadequate protection. These distinctions guide the main response to each problem. Missing updates require reliable patch deployment and verification. Before a fix exists, monitoring, applicable mitigations, exposure reduction, and response become especially important. Configuration errors require reviewing settings and limiting access to legitimate needs. Credential weaknesses call for secure setup, strong unique credentials, and safer device design. A device may have several weaknesses, so fixing one category does not automatically resolve every exposure. The four historical examples illustrate different primary weaknesses, rather than four exclusive boxes for every incident.
Unpatched Software
Equifax Shows Why an Available Patch Is Not an Applied Patch
Equifax’s twenty seventeen breach involved a known weakness in the Apache Struts web framework. A vendor fix existed, and federal authorities had warned organizations to patch. The affected dispute portal remained vulnerable when attackers accessed sensitive information. Personal data relating to roughly one hundred forty-seven million people was exposed. The central distinction is between a published patch and protection on an actual system. Teams must know which assets are affected and who owns each update. Advisories need to reach current responsible staff, and deployment needs verification. An email or an incomplete scan does not necessarily prove the vulnerable system was fixed. Downtime, compatibility testing, limited resources, and many vendors can complicate deployment. A safe change plan can include testing, rollback preparation, and temporary protection where appropriate. These practical constraints explain the challenge, but they do not eliminate the continuing exposure window.
Zero-Days
Before a Fix Exists, Layered Defense Still Matters
A zero-day is exploited before a relevant fix is available. The vendor may not yet know about the flaw, or may know and be preparing an update. A zero-day exploit is the method used to take advantage of it. Initial twenty twenty-one Microsoft Exchange attacks exploited flaws before fixes were available. Defenders could not install a patch that had not yet been released. That does not mean detection or complete disconnection were their only possible protections. Appropriate monitoring, segmentation, reduced exposure, and available vendor-recommended mitigations can also help. Once updates became available, affected organizations needed to apply them and investigate suspected compromise. Microsoft explained that patching or interim mitigation did not automatically evict an adversary already present. Authorized research and reporting can improve defense, while undisclosed stockpiles can extend exposure. When a fix exists but a system lacks it, the remaining window is a patch gap.
Misconfiguration
Correct Software Can Still Have Unsafe Permissions
Misconfiguration means settings or permissions create inappropriate exposure. The software may perform exactly as designed while allowing more access than the organization intended. A missing protection or overly broad account permission can create that problem. Least privilege gives an account or component only what its legitimate function requires. A cloud bucket intended to be private may become accessible through inappropriate permissions. Do not assume every cloud product ships with public storage as its default. Capital One’s twenty nineteen incident involved configuration weaknesses and cloud access. Its announcement described roughly one hundred million affected people in the United States and six million in Canada. That included applicants and customers, rather than only one hundred million existing customer accounts. The later federal conviction record described misuse of misconfigured cloud accounts, including Capital One. Review configuration, credential access, and permissions together, rather than reducing every breach to one setting.
Credentials and IoT
Mirai Exploited Familiar Credentials on Exposed Devices
Default credentials are preset logins supplied with a device or system. When a shared factory password is publicly known, leaving it usable can provide weak protection. A changed password can still be weak if it is common, short, reused, or easily guessed. In twenty sixteen, Mirai compromised internet-connected routers, cameras, and digital video recorders. The FBI described attackers exploiting exposed devices with common default usernames and passwords. Compromised devices formed a botnet, a collection controlled together. Many small devices could then generate substantial aggregate disruption through distributed denial-of-service attacks. A new software flaw was unnecessary when a familiar login already provided access. Use secure setup and strong unique credentials where the product supports them. Limit unnecessary exposure and maintain supported updates; unsafe unsupported devices may need replacement. Some credentials are fixed or difficult to change, so manufacturers also need secure defaults and usable controls.
CVE
A Shared Identifier Names a Flaw Without Measuring Its Risk
CVE stands for Common Vulnerabilities and Exposures. Its identifiers help vendors, researchers, and security tools refer to the same published vulnerability. An identifier contains the CVE prefix, a four-digit year, and a sequence number. The sequence has at least four digits, and can be longer. The year relates to assignment or earlier public disclosure under the program’s rules. It does not necessarily identify discovery, introduction into software, or the date a fix appeared. The Struts flaw associated with Equifax is CVE twenty seventeen, five six three eight. That identifier names the weakness without embedding a severity score. Read the record and vendor advice to identify affected products and versions. Then compare them with the organization’s own inventory and installed versions. Not every weak password, configuration error, or organizational risk receives a separate CVE record.
CVSS
Severity Helps Prioritize, but Context Determines the Response
CVSS means Common Vulnerability Scoring System, and it describes technical severity. Its numerical scores run from zero to ten. Zero is None; zero point one through three point nine is Low. Four through six point nine is Medium, and seven through eight point nine is High. Nine through ten is Critical, so the hypothetical nine point four score is Critical. Assess that finding urgently, while checking whether the actual system is affected and exposed. Factors include attack reach, complexity, required privileges, user interaction, and effects on confidentiality, integrity, and availability. Version four also organizes Base, Threat, Environmental, and Supplemental metrics. A score is an input to risk assessment, rather than a universal deadline or likelihood estimate. Known exploitation, system importance, effective controls, and applicable requirements also inform the response. CISA’s known-exploited catalog supplies another input; an exposed, actively exploited flaw may outrank an inapplicable higher score.
The Lifecycle
Two Exposure Windows Require Different Responses
A typical lifecycle begins when a weakness is introduced during development or configuration. A researcher, vendor, or attacker may discover it. Authorized reporting and coordination can allow work on protections before detailed public disclosure. The vendor releases a fix, and affected users or organizations must deploy and verify it. The sequence is illustrative, rather than guaranteed for every vulnerability. Public disclosure can occur before or after release, and some weaknesses never complete every stage. The first window exists before a relevant fix is available. Exploitation during that period is zero-day exploitation, requiring other appropriate protections and response. The second window is the patch gap, after release but before protection reaches an affected asset. An upstream fix may also need integration by downstream suppliers before end users can install it. Discovery, release, and actual protection are separate milestones; closing the final gap requires verified coverage.
Coordination and Operations
Responsible Reporting Must Be Followed by Verified Protection
Responsible disclosure, often called coordinated disclosure, starts with authorized reporting and arranging a response. The aim is timely protection and notice, while considering harm from premature technical exposure. Policies vary across researchers, vendors, coordinators, and affected products. Google Project Zero uses a ninety-day fix deadline and, when fixed before it, a thirty-day adoption period. Ninety days is not a universal industry rule or legal deadline. Operational protection then requires identifying affected assets and setting appropriate priorities. Combine technical severity with actual exploitation, exposure, and business or safety impact. Test and deploy through a suitable change plan, assigning clear responsibility for completion. Verify the relevant versions or settings changed, and investigate evidence of prior compromise. Track exceptions, downstream delays, unsupported systems, and any remaining exposure. Patching reduces weaknesses; access limits, detection, response, and recovery can also reduce likelihood or consequences.
Review and Apply
Explain the Weakness, the Window, and the Priority
Use the review to distinguish the weakness, exposure window, and practical response. A vulnerability is the weakness, and an exploit is a method taking advantage of it. Risk combines likelihood and potential impact in the actual environment. Early ProxyLogon defenders could not install an unavailable fix, but other applicable protections still mattered. Capital One illustrates configuration and access-control problems, rather than simply leaving an available software update unapplied. A CVSS score of nine point four means Critical severity and deserves urgent assessment. Actual response priority also considers applicability, exposure, exploitation, impact, and relevant requirements. Mirai shows how familiar credentials on exposed devices can enable compromise without a zero-day. CVE provides a shared identifier; CVSS describes severity without replacing the complete risk decision. Before a relevant fix is available, use suitable layered protections and response. After release, close the patch gap by deploying the change and verifying each affected asset.
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 The Weak Points in Systems and Human Behavior That Criminals Exploit Most Often
What is the difference between a vulnerability, an exploit, and risk in cybersecurity?
What is the difference between a zero-day and an unpatched vulnerability?
What do CVSS scores mean, and should the highest score be fixed first?
What is a security misconfiguration, and what did the Capital One breach show?
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 →