CSC347: Introduction to Information Security
Week 4: Prepared statements, Course Intro and Terminolgy. . .
Plan for today
I Admin (2 minutes: zip files and 48h vs. 24h late)
I Discuss prepared statements (10 minutes)
I Terminology and Principles (40 minutes)
I Break (5 minutes)
I Principles and Processes (50 minutes)
Prepared statements
References: OWASP
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Defenses
Defenses
I Primary Defenses:
I Prepared Statements (with Parameterized Queries)
I Stored Procedures
I Allow-list Input Validation (white listing)
I Escaping All User Supplied Input (input sanitization)
Defenses
I Primary Defenses:
I Prepared Statements (with Parameterized Queries)
I Stored Procedures
I Allow-list Input Validation (white listing)
I Escaping All User Supplied Input (input sanitization)
I Additional Defenses:
I Also: Enforcing Least Privilege
I Also: Performing Allow-list Input Validation as a Secondary
Defense
Important
Parameterized queries force the developer to first define all the SQL
code, and then pass in each parameter to the query later. This
coding style allows the database to distinguish between code and
data, regardless of what user input is supplied.
Prepared statements ensure that an attacker is not able to change
the intent of a query, even if SQL commands are inserted by an
attacker. In the safe example below, if an attacker were to enter the
userID of tom’ or ‘1’=‘1, the parameterized query would not be
vulnerable and would instead look for a username which literally
matched the entire string tom’ or ‘1’=’1.
Source OWASP again
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Course Intro (finally)
US-Cert Weekly vulnerabilities.
I This week’s vulnerabilities: here
I Weekly bulletings: here
A lot of buffer overruns, integer overflow and SQL injections listed
(plus other things not yet covered)
https://us-cert.cisa.gov/ncas/bulletins/sb21-270
https://us-cert.cisa.gov/ncas/bulletins
Terminology
I Vulnerability
I Exploit
I Impact
Terminology
I Vulnerability: A weakness which can be exploited Common
Weakness Enumeration
I Top 25, how many have we already covered? (buffer, sql, path,
integer)
I Exploit: Using the vulnerability
I Impact: The effect on the system or users
https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html
https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html
Terminology
I Confidentiality
I Integrity
I Availability
Terminology
I Confidentiality: Information is disclosed only to authorized
parties
I Integrity: Information remains unchanged in transit and at rest.
Only authorized parties can change it.
I Availability: Authorized parties have timely and uncompromised
access.
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209 –> Availability
I SQL Injection
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209 –> A
I SQL Injection –> I, C
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209 –> A
I SQL Injection –> I, C
I Buffer overrun
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209 –> A
I SQL Injection –> I, C
I Buffer overrun –> C, I, A
I Directory Traversal
Testing your understanding
What does each of the following compromise (CIA)?
I Fork bomb in csc209 –> A
I SQL Injection –> I, C
I Buffer overrun –> C, I, A
I Directory Traversal –> I, C
Authentication and accountability
I Authentication: Ensuring that a user, data or software is
genuine
I Accountability: maintinaing identity and activity logs
Security as a continuous process
I Assessment
I Analysis of the environment and the system security
requirements. During this phase, you create and document a
security policy and plans for implementing that policy.
I Protection
I Implementation of the security plan (e.g., secure configuration,
resource protection, maintenance).
I Detection
I Identification of attacks and policy violations by use of
techniques such as monitoring, log analysis, and intrusion
detection.
I Response
I Handling of detected intrusions, in the ways specified by the
security plan.
This course
I Software Security: what is bad code, writing good code, buffer
overruns, sql injection, xss
I System Security: how to protect your system, permissions,
scripts, hardware, passwords, intrusion detection, fingerprinting
I Network Security: introduction to networking, firewalls,
processes, scanning networks, footprinting, routing
I Cryptography: How to keep secrets, share them only with
specified parties, know that you are speaking with whom you
intended to speak with.
I Social engineering: fishing, people and trust
Assignments and Labs
Often you will be . . .
I given a code base with vulnerabilities and you are expected to
fix them
I carrying out (writing) code in a sandboxed environment to
achieve a goals . . . and then defend against them.
I given a system and need to determine whether it has been
compromised, and if so how, what is the damage, how can it
be prefixed
I given access to a system to obtain information.
I ==> altnerate between red, blue, purple teaming on
assignments and labs.
I competing with your peers (sometimes) in fun activities
What is This Course About?
I Introduction to various topics in information security:
I Executables (Buffer overruns)
I PHP, SQL injections
I XSS
I Passwords, Hashing
I Permissions, ACLs
I Fingerprinting, Intrusion detection
I Cryptography
I Network security
I Programming languages of choice
I C, PHP, SQL, Bash, Python, Javascript
What is This Course About? (2)
I Overview of various topics and a practical introduction
I (Debugging) tools: gdb, valgrind, strace, ltrace, JS browser
inspectors, industry strenght security tools
I Build automation tools: make
I Version control: git
I Interacting with a UNIX-like OS using the Bash shell
notes: With the help of these tools you will spend less time
debugging, more time being productive.
After taking this course, you should be able to. . .
I Diagram and explain the memory usage/layout of an arbitrary
executable
I Analyse source code in C, JS, PHP, SQL, identify and fix
programs that exhibit certain security vulnerabilities
I Avoid writing code with certain security vulnerabilities
I Use tools to test for certain vulnerabilities.
I Design secure architectures for software projects
I Explain how common security vulernatibilies work
What assets need to be protected
I Personal security
I Operations security
I Communications security
I Network security
I Information security
More definitions
CVE defines a vulnerability as:
“A weakness in the computational logic (e.g., code) found in
software and hardware components that, when exploited, results in a
negative impact to confidentiality, integrity, or availability.
Mitigation of the vulnerabilities in this context typically involves
coding changes, but could also include specification changes or even
specification deprecations (e.g., removal of affected protocols or
functionality in their entirety).”
More definitions and terminology
I exploit a vulnerability: take advantage of the vulnerability
I prevention: (ie prevent smashing the stack by randomizing the
stack)
I detection: knowing that you have been hacked. ie Tripwire
I recovery: after an attack, restoring CIA for example.
I scanning: probe systems on the internet (ie nmap)
I Vulnerability Scanner: a scanning tool that looks for known
weaknesses
I Sniffer: software that captures network traffic while in transit
(ethereal)
More definitions and terminology
I Exploit: a ready to run program that takes advantage of known
weaknesses
I Social engineering: exploit human weakness ie. shoulder
surfing, scavenging, pets for passwords, drop USB key
I Side-channel attack: eavesdropping, acoustic keyboard
eavesdropping
I root kit: software designed to hide the fact that a system has
been compromised. for example, replace ps on a unix system to
hide the fact that rogue processes are running.
I Leet (l33t speak): slang used by hackers to obfuscate
discussions in newsgroups
I Honeypot: a server that acts as a decoy
I Threat modelling: a formal approach to security, see Microsofts
Security Threat Modeling Tool, or the doc, the ppt
I Penetration Testing
I Red team, Blue team, Purple Team
Some links for tools and resources
I Virus Total
I
I US Cert
I haveibeenpwned
I https://openwrt.org/
I Sectools
I Vulnerability Scanners
I Forensic Tools
https://www.virustotal.com/gui/
https://www.kali.org/
https://us-cert.cisa.gov/
https://haveibeenpwned.com/
https://openwrt.org/
https://sectools.org/
https://owasp.org/www-community/Vulnerability_Scanning_Tools
https://github.com/Cugu/awesome-forensics
Principles
I Principle #1: The defender must defend all points; the
attacker can choose the weakest point.
I Principle #2: The defender can defend only against known
attacks; the attacker can probe for unknown vulnerabilities.
I Principle #3: The defender must be constantly vigilant; the
attacker can strike at will.
I Principle #4: The defender must play by the rules; the
attacker can play dirty.
Principles to Live by
I Compartmentalize:
I Compartmentalization is a concept well understood by
submarine builders and by the captain of the Starship Enterprise.
On a submarine, a leak that is not contained to the quarter in
which it originated will cause the whole submarine to be filled
with water and lead to the death of the entire crew. That’s why
submarines have systems in place to isolate one part of the
submarine from another. This concept also benefits computer
security. Compartmentalization is all about damage control.
The idea is to design the whole to consist of smaller connected
parts. This principle goes well together with the next one.
Principles to live by
I Utilize the principle of least privilege:
I Each part of the system (a program or a user) should be given
the privileges it needs to perform its normal duties and nothing
more. That way, if one part of the system is compromised, the
damage will be limited.
Principles to live by
I Perform defense in depth:
I Defense in depth is about having multiple independent layers of
security. If there is only one security layer, the compromise of
that layer compromises the entire system. Multiple layers are
preferable. For example, if you have a firewall in place, an
independent intrusion detection system can serve to control its
operation. Having two firewalls to defend the same entry point,
each from a different vendor, increases security further.
Principles to live by
I Do not volunteer information:
I Attackers commonly work in the dark and perform
reconnaissance to uncover as much information about the target
as possible. We should not help them. Keep information private
whenever you can. But keeping information private is not a big
security tool on its own. Unless the system is secure, obscurity
will not help much.
Principles to live by
I Fail safely:
I Make sure that whenever a system component fails, it fails in
such a way as to change into a more secure state. Using an
obvious example, if the login procedure cannot complete
because of some internal problem, the software should reject all
login requests until the internal problem is resolved.
Principles to live by
I Secure the weakest link:
I The whole system is as secure as its weakest link. Take the time
to understand all system parts and focus your efforts on the
weak parts.
Principles to live by
I Practice simplicity:
I Humans do not cope with complexity well. A study has found
we can only hold up to around seven concepts in our heads at
any one time. Anything more complex than that will be hard to
understand. A simple system is easy to configure, verify, and
use. (This was demonstrated in a recent paper, “A Quantitative
Study of Firewall Configuration Errors” by Avishai Wool:
http://www.eng.tau.ac.il/~yash/computer2004.pdf.)
The Ten Immutable Laws of Security
Law #1: If a bad actor can persuade you to run his program on
your computer, it’s not your computer anymore
Law #2: If a bad actor can alter the operating system on your
computer, it’s not your computer anymore
Law #3: If a bad actor has unrestricted physical access to your
computer, it’s not your computer anymore
Law #4: If you allow a bad actor to upload programs to your
website, it’s not your website any more
The Ten Immutable Laws of Security (cont.)
Law #5: Weak passwords trump strong security
Law #6: A computer is only as secure as the administrator is
trustworthy
Law #7: Encrypted data is only as secure as the decryption key
Law #8: An out of date virus scanner is only marginally better than
no virus scanner at all
Law #9: Absolute anonymity isn’t practical, in real life or on the
Web
Law #10: Technology is not a panacea
Design principles for computer security:
P1 SIMPLICITY-AND-NECESSITY: P2 SAFE-DEFAULTS: P3
OPEN-DESIGN: P4 COMPLETE-MEDIATION: P5
ISOLATED-COMPARTMENTS: P6 LEAST-PRIVILEGE: P7
MODULAR-DESIGN: P8 SMALL-TRUSTED-BASES: P9
TIME-TESTED-TOOLS: P10 LEAST-SURPRISE: P11
USER-BUY-IN: P12 SUFFICIENT-WORK-FACTOR: P13
DEFENCE-IN-DEPTH: P14 EVIDENCE-PRODUCTION: P15
DATA-TYPE-VERIFICATION: P16 REMNANT-REMOVAL: P17
TRUST-ANCHOR-JUSTIFICATION: P18
INDEPENDENT-CONFIRMATION: HP1 SECURITY-BY-DESIGN:
HP2 DESIGN-FOR-EVOLUTION: Trust but Verify
Monitoring
I Reasons for Monitoring
I Monitoring compliance
Logging plus automated log analysis and reporting
Manage Business Risk
I How many people in the organization
I Larger companies require more internal monitoring
I How many users of a systems
I What type of data is stored
I PII
### Manage Business Risk
I How many people in the organization
I Larger companies require more internal monitoring
I How many users of a systems
I What type of data is stored
I PII
Most have internal audits, external audits, systems department, or
info sec department.
Benefits of Monitoring
I Problems can be identified faster and earlier
I Cost savings (inefficient resource use, malicious resource use,
prevent costly breaches).
I Validate existing controls
I Identifying vulernatibilies
I Providing evidence for investigations
I Improved understanding of environment
I Cost reduction
Logging and Monitoring tools
I All OSses have them (Windows, Mac, Linux)
I Event logs
I syslogs
I application logging (python, Java, etc. )
Monitoring data environments
I protecting employee and user Information
I segregation of duties
I verifying data integrity
I protecting records
Also monitoring physical environments (access, video surveilance)
Building monitoring systems
I Monitoring and identifying system resources used
I Analysing network traffic and connections
I Scanning for malicious code (fingerprinting systems)
I Probing for system and network vulnerabilities
I Verifying file and data integrity
I Log retention and log storage policies (backup, access,
integrity)
I Searchability of logs (src/dest addresses, ports, protocol, time
stamp)
I Reporting and Alerting
Other topics
I Risk Assessements
I assess vulnerabilities
I determine response and safeguards
I Security Threat assessements
I Security triad (C I A)
I to employees and assests
I likelyhood and impact
I Threat Risk Assessements
I identify how targets can be compromised and assess level of Risk
I Vulnerability assessements
I assign relative levels (low to very high, 1 to 5)
I Compliance assessements
I determine level of compliance with standards, policies and
Processes
I Digital forensics and Investigations
I Privacy
I Business Continuity Management
I Enterprise Security Architecture
I Security Policies and standards