Introduction to Security Kira Chan K. Chan: CSE435: Software - PDF document

11/26/19 Introduction to Security Kira Chan K. Chan: CSE435: Software Engineering Software expectation • In a regular messaging application, what do you expect? • Let's assume you want to use it to meet your friend for Friday night dinner. • Messages are delivered • Delivers within a time limit threshold • No one else is reading your messages • Message is not altered • Application does not “lag” • Etc K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 1

11/26/19 Terminology • “A computer is secure if you can depend on it and its software to behave as you expect (intent).” ​ • ‘ Trust describes our level of confidence that a computer system will behave as expected.’ (intended)​ [Garfinkel & Spafford, Kasten] ​ K. Chan: CSE435: Software Engineering Why should we consider security? • Can you build a messaging application that satisfies requirements • Who are the requirements made for? • Stakeholders? • Users? • Does every user conform to the expectations you have set? • Resources and information contain monetary or other values • Security breaches could be damaging to your reputation • When is security usually taken into consideration? • Security is often an after thought • Added onto a system, it may not fully address the underlying issue • Lots of new “Band-Aids” to patch an issue, causes inefficiency K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 2

11/26/19 Potential impact • Wannacry • Encrypts user data and demand ransom to decrypt it • https://www.symantec.com/blogs/threat-intelligence/wannacry-ransomware-attack • Say I encrypted your laptop, your final exam is tomorrow • Ransom is every asset you have • Do you pay it? • Safety? • What if critical systems are compromised? K. Chan: CSE435: Software Engineering De Definition (NIST) • Computer security is the protection afforded to an automated information system in order to attain the applicable objective of preserving the integrity, availability and confidentiality of the system’s resources • https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-14.pdf K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 3

11/26/19 Confidentiality, Integrity and Availability • Confidentiality : information are not disclosed to unauthorized parties • Integrity : assure that information and program are only changed in an authorized manner • A message is actually from where it claims to have come from • Mailman delivers you a mail from your best friend overseas, how do you know if this message have not been modified? • Availability : assures that the systems work promptly, and services are not denied to authorized users when they request them K. Chan: CSE435: Software Engineering Castle analogy Img source: McCallum K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 4

11/26/19 Security challenges. • Defending a system is hard since we must secure all weak points • Attacker only needs to find one exploit • Users do not like complicated systems • Benefit of security is not considered until a breach occurs • IT tech person, why do we even hire this guy? • Impediment to the user K. Chan: CSE435: Software Engineering Terminology • Security Policy : a set of rules and practices that specify or regulate how a system provides security services to protect sensitive and critical system resources • Vulnerability : a flaw or weakness in a system that can be exploited • Threat : a potential violation of security; a possible danger that might exploit a vulnerability • Attack : an assault on the system that derives from a threat. • Threats carried out K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 5

11/26/19 Threats • Hardware: physical devices – easy target • “Involuntary computer-slaughter” • Accidental acts not intended to do harm • E.g. Spilling a drink on computer • “Voluntary computer slaughter” – machinicide: • Purposely break a machine • Software: equipment worthless without software • Deletion • Modification • Theft Slide provided from Dr. Cheng K. Chan: CSE435: Software Engineering Why are we talking about this? • Time is money • Organizations want a product that makes money, so time spent not making money producing software is wasted time. • Monetory consequences are often not considered until a breach. • Example: CSE3xx programs. • Did you consider security when you developed your programs? K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 6

11/26/19 Patches K. Chan: CSE435: Software Engineering Patches • Changes made to fix, improve or update your system • What are patches used for? • Bug-fixes • Improvements • New features • Why can we not just patch security issues away? K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 7

11/26/19 When to use patches for security • Security should be defined in your original design • Patches should only be given as emergency solution • User ignores patches a lot of time • Patches may not fix the fundamental issues K. Chan: CSE435: Software Engineering How do we provide security to a system? • Easiest way: no access. • Challenge is to prevent unauthorized access to system, while causing the least amount of impediment to legitimate users. User Security for experience system K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 8

11/26/19 How to design your system? • Design of security should be as small and simple as needed • Easy to test/verify its strength, fewer flaws • Open Design : security mechanism should not be a secret! • Why? • Experts can review and point to flaws • Reverse engineering can expose your software • You will not know if your software have been compromised K. Chan: CSE435: Software Engineering How to design your system (cont.) • Psychological acceptability : the security mechanisms should not interfere with the work of the user • Consider our messaging app • Asks for user password every 30 seconds • Less extreme of an example: require restart every 12 hours • User will disarm if not! • Layering : Multiple layers of security. Failure at one point will not leave your system compromised • Example: messaging application • Encrypt stored messages • Ensure other applications on same device cannot access those files • Least astonishment : no surprises! • Functions should conform to user expectation K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 9

11/26/19 Remainder of presentation • I will focus on what you can do as a developer to help secure your system • What to do and what not to do K. Chan: CSE435: Software Engineering Risk Assessment • Three questions to answer: • What am I trying to protect? • What do I need to protect against? • How much time, effort, and money am I willing to spend to obtain these protection? • Three key steps: • Identify assets • Identify threats • Calculate risks • Risk: expected loss from the probability that a threat that will exploit a vulnerability in the system Slide provided from Dr. Cheng K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 10

11/26/19 Identify Asset • What are you trying to protect against? Recall CIA • Data? • Message confidentiality? • System resources? • Availability? • Categories of vulnerabilities: • Corruption (loss of integrity) • Leaky (loss of confidentiality) • Unavailable or slow access (loss of availability) K. Chan: CSE435: Software Engineering Identify Threats • What is the threat? • Hackers? • Political opponents • Rival companies • Activist • What is the intent/objective of the threat? K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 11

11/26/19 3 classes of intruder skill level • Apprentice : minimal technical skills • Use existing technologies • Most intruders belong in this category • Easy to defend • Why? • Journeymen : modifies and extends attack toolkits • Master : high-level technical skills • Capable of discovering new attacks • Understands underlying protocol used • Writes their own attacks and toolkits • Hardest to defend against K. Chan: CSE435: Software Engineering Calculating risk • How likely is a particular threat? • What is the chance that X will happen, and what is the consequence of it? • If an event happens on regular basis, you can estimate based on previous experiences. K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 12

11/26/19 Different kind of attacks you may consider as a developer K. Chan: CSE435: Software Engineering Denial of Service (DoS) • Attack on availability of a system • Deny legitimate user the ability to use a system or its resources • Distributed Denial of Service attack (DDoS) K. Chan: CSE435: Software Engineering K. Chan: CSE435: Software Engineering 13