Mondla_csss5220_chapter_4

.docx

School

Webster University *

*We aren’t endorsed by this school

Course

5220

Subject

Information Systems

Date

Dec 6, 2023

Type

docx

Pages

2

Uploaded by AdmiralGalaxy8674

Report
1) When a trustworthy lecturer wants to share the code with their students while also assuring its security, a strategy is established to demonstrate the code's legitimacy. By letting the students know in advance that she would be publishing a program with the codename P1, the lecturer hopes to increase their confidence in the impending code. Even with this model's seeming security, there could be a weakness that a dishonest student like Mel could exploit to add his own hazardous code. Mel's strategy would rely on the alert system and the student's trust in the teacher's communication. Mel can rely on the professor's warnings; thus, she can devise the following plan: Phishing Notification: Mel creates a fake notification by imitating the professor's communication style. By distributing this notification to the entire class, he mimics the professor's email or messaging format. The announcement may read, "Upcoming Code Release: Watch for P1 on the class server!" as an illustration. Early Upload: Mel uploads his malicious code, known as P1, to the class server as soon as he sends out the phishing mail. Since the notice appears to be from the professor and they trust the communication, students would expect to find the true P1 on the server. Trust Exploitation: Some students may unintentionally download Mel's malicious code when they first access P1 from the server because they believe it to be the authentic P1 that the professor has approved. This is so that students won't run any more checks because the notice has been successful in instilling a sense of confidence. Malicious Payload: The potentially dangerous elements of Mel's harmful code might range from malware that corrupts the students' computers to code that steals private information, crashes the server, or endangers their data security. Here, Mel abuses the pupils' ingrained belief in the professor's announcements. By mimicking the professor's communication style and timing, he tricks them into believing that his malicious code (marked as P1) is the real release from the professor. Therefore, some students could unwittingly download and run the harmful software, endangering their devices and even the whole class network. The professor and students must take additional security precautions to address this threat: Verification: Students should use a variety of communication channels or techniques to confirm the veracity of announcements. Digital Signatures: The professor might use her private key to digitally sign the code and then give the students access to her public key for confirmation. Students can confirm the authenticity of the code in this way. Code evaluation: Before executing the code, instruct students to evaluate it for any erratic or strange behavior.
• Multi-step verification: Use a multi-step verification process where the professor notifies students of the release both in advance and right before they submit the code. • Security education: Making students aware of the risks associated with phishing and social engineering can make them more alert to such ploys. The professor's strategy aims to increase trust in code distribution, but a determined bad guy like Mel may exploit this confidence to add harmful code. To guarantee the validity and security of distributed code, it is vital to combine technological safeguards with student security awareness to lessen this risk. 2) A zero-day vulnerability is one that has not yet been patched or otherwise addressed by the party or parties responsible. The term "zero-day attack" can be used to describe an attack that takes place exactly zero days after the vulnerability is discovered or the actual attack itself. Once made public, a zero-day vulnerability evolves into an n-day or one-day vulnerability. The software vendor is often informed when a software product is discovered to contain a potential security problem so that necessary action may be taken. A software developer can modify the code and publish a patch if given enough time. It could take some time for prospective attackers to discover the vulnerability, but even if they do, the fix should show up first. A hacker, though, may discover the vulnerability for the first time. The attack cannot be stopped since the vulnerability cannot be identified in advance. Zero-day exploits can be extremely difficult to locate. Anti- malware software, as well as some intrusion detection and prevention systems (IDSs) and intrusion prevention systems (IPSs), are commonly rendered ineffective due to the lack of an attack signature. As a result, user behavior analytics are the most effective way to detect a zero-day attack. Most entities having network access exhibit normal usage and behavior patterns. Activities that aren't part of normal corporate operations might indicate a zero-day attack.
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help