Soma-notes - User contributions [en]

SystemsSec 2018W Lecture 23

2018-04-08T21:41:48Z

Michael B: /* Notes */

==Audio==

[https://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec23-04Apr2018.m4a Lecture 23 Audio]

==Notes==
===Network Monitoring===
Network monitoring is a very general concept and performed for many reasons. Your ISP might monitor the network for congestion or bad traffic. An organization may monitor the network for security reasons.

===Encryption===
Monitoring networks has become harder recently due to encryption. For example:
- Web traffic is all on TLS
- Emails are being encrypted
- DNS: Used to be wide open, tried to secure it (DNSSEC)
- If left in the clear, open to monitor and manipulation by anyone, which is bad
- It gives you more information than just a src/dst IP would. Why? "The Cloud"
- Usually multiple IPs for one service, or many services for one IP
- DNS will get you what you want, so now efforts to tunnel DNS over TLS

Even if we assume encryption isn't a problem, how do we "'''secure'''" (find out if bad things are occuring) a network? How do you '''understand what the network is doing'''? Sysadmins care about security, but ultimately, they care about what is going on inside their network.

Enterprises will usually forgo encryption entirely, or have the keys to decrypt due to legal obligations. They may set up a man in the middle by terminating TLS connections at a certain point and re-initiating their own. They can accomplish this by installing their own root certs.

===Without Encryption===
Even with everything in plaintext, understanding a network still isn't easy. What does it even mean to understand a network? It's not so much as a protocol complexity issue, but more of a "everything you connect to does crazy things and it's hard to know what" issue. What we need is '''a model''', so that when things deviate from the model we can tell.

How to we learn a model?
- sit and sift though traffic. (tedious and usually ineffective)

- '''aggregate things:''' Classify and look at relationships
- But how? Not always easy
- Use src/dst ip/ports? When few computers, awesome, but not for modern networks
- Modern networks are too dynamic, always changing and too many IPs

- Solution: block classes of traffic via proxy?
- Haven't solved the problem, too much traffic still
- '''No Whitelists:''' too many sites/people
- '''No Blacklists:''' might partly work, but too many large holes
- '''No Anomaly Detection:''' too much stuff, too random.
- Anomaly rate will be high (tail of curve too fat)
- If we cut off tail, now people are mad and circumvent us

===Clustering===
The gist of clustering is: I don't know the right aggregates, so let's automatically aggregate it instead. If we combine this with anomaly detection after, maybe we can have some success?
- Clustering -> Aggregates -> Anomaly Detection -> Profit???
Our usual clustering algorithms are O(n^2), not possible with a high traffic volume. Even O(nlogn) is too much. Maybe using sliding window on streaming data?

Remember, we are '''trying to build a model'''. What if we could quickly build this model and check it (using machine learning)? If our '''model building is fast''', and we can '''check in linear time''', it could work. But how can we limit our data size?

* Limit sample by using small time window of data
* Build model on time window, adjust over time

Now that we have our sample data, how do we build our model? The first thought is to model the weirdness, but this is wrong. Instead, we should '''model what is normal''', '''then check for weirdness'''. Alright, so how do we do this?

===PN-Grams===
N-grams are substrings of content. But we need more than this, we also need the position as well. There we look at pn-grams (position n-grams). These enable us to '''forgo inspecting whole packets''', and instead just '''look at a few bytes in a specific position'''. But how do we find these pn-grams?

* Start with all traffic, then take a sample
* In sample, compute frequency of all pn-grams
* Using pn-grams, randomly pick one with a frequency of about 50% (40-60)
** We now have two classes, one with the pn-gram in it, one without
* Do this recursively until we get down to aggregates with about 2% frequency
** Result is a decision tree of pn-grams, where leafs are our aggregates

Turns out that this method classifies traffic in extremely meaningful ways (TCP vs Non-TCP, etc). It works even better if we remove packet headers due to redundancy. Finally, the closer the aggregates are in the tree, the more similar they are. If you don't understand why this occurs, don't worry, some guy did a PhD on this.

For more info, search online for:
*NetADHICT
*Hijazi

SystemsSec 2018W Lecture 10

2018-03-01T06:32:32Z

Michael B: /* Notes */

==Audio==

[https://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec10-07Feb2018.m4a Lecture 10 Audio]

==Notes==

===Logic Errors===
* Accidental (motive)
* Discovered
* Variable impact

===Backdoors===
* On purpose
* Engineered
* Severe impact

When dealing with a sophisticated attacker, you can't tell the difference
A good attack will make it seem like a logic error. The only difference between the two is motive.
A vulnerability can be discovered by anyone and is as good as a backdoor.

This means that any strategy that deals with software vulnerability/quality checking isn't full proof; you are never safe.
Moreover, everyone uses the same code, so what's the difference between hardened bunker and a school? They all run the same code.
How do you write portable code? Manually port it. Watch it break, fix it.

==Building with Security in Mind==

Security must be built in from the beginning (Replace security with any other property: performance, portability, etc).
We have a process for portability, so why not security?
Same thing, but the requirements have changed slightly. We need to adapt. New attack? Time to adapt your code.

Main point: think about software engineering from a security perspective. Requirements still change just like we are used to, but instead of requests for new features, we have other things to worry about.

Now that we have this mindset, our original point changes: continue to think of security in terms of normal software development, but not with it defined by requirements. We can try to list requirements in security, but it's impossible. Requirements are useless because, like for regular software development, they are just words telling us what needs to be accomplished, this leads to crap code and nothing getting done.

Therefore we need something else: something that will assume unintended requirements that comes with security. So we do what we normally do when we have poor requirements, we evolve them.
* Normally we evolve our requirements by taking in external input to the software engineering process (user data, feedback, etc)
* Evolving in security is different.
:* From a business perspective, no return on investment.
:* Hard to measure things when they are actively trying to deceive you
::* Solution: Intrusion detection?

===Solutions===
Only difference between devops and security is deception, requirements are trying to hide.

'''Bug bounties''' are not crowd sourced, the people who find these are professionals, not just the general crowd.
*Google project 0: notorious due to strict timelines (90 days)
When you find bugs you are a whistle blower (nobody likes a whistle blower), but nobody in organizations cared, this lead to full disclosure.
*Bugtrack: mailing list going out to the world (full disclosure)

===Basic Checks===
Following list is the known list that attackers check for at first, like grammar copycheckers:

'''SQL Injections''': (backronym, sequel, used to actually be spelled sequel)
* Query language for databases (domain specific programming language for databases)
* Usually dynamically generated code from untrusted user input
* Equivalent of writing a program using arbitrary input: e.g. I can write a program in your program.

See the patterns? A lot of functionality when you only need one function. Keep this in mind when you are writing code

'''Shellcode injection'''

Computer Systems Security (Winter 2018)

2018-02-11T05:11:45Z

Michael B:

==Course Outline==

[[Computer Systems Security: Winter 2018 Course Outline|Course Outline]]

==Experiences==

You are required to complete 9 experiences throughout the semester.

* [[Computer Systems Security: Winter 2018 Experiences|List of Experiences]]

==Assignments==

Assignments will be posted here as they become available

* [[Computer Systems Security: Winter 2018 Assignment 1|Assignment 1]]
* Assignment 2
* Assignment 3
* Assignment 4

==Resources==

Here are some resources you may find useful:

* [http://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/comp4108-2018w.ova A Virtualbox OVF image for Ubuntu 17.10.1]
* [https://openstack.scs.carleton.ca The SCS openstack cluster]. Note that you can only access this from the Carleton network. To access from elsewhere, [https://carleton.ca/its/help-centre/remote-access/ VPN in] to the university. (On Linux you can also use openconnect rather than the Cisco software provided by Carleton.)

If you cannot access openstack, try [http://www.scs.carleton.ca/webacct changing your SCS password].

==Schedule==

===January 8, 2018===

[[SystemsSec 2018W Lecture 1|Introduction]]

===January 10, 2018===

[[SystemsSec 2018W Lecture 2|Threat Modelling]]

===January 15, 2018===

[[SystemsSec 2018W Lecture 3|Common tools]]

===January 17, 2018===

[[SystemsSec 2018W Lecture 4|passwd]]

===January 22, 2018===

[[SystemsSec 2018W Lecture 5|Networking 1]]

===January 24, 2018===

[[SystemsSec 2018W Lecture 6|Virtual machines 1]]

===January 29, 2018===

[[SystemsSec 2018W Lecture 7|Cryptography 1]]

===January 31, 2018===

[[SystemsSec 2018W Lecture 8|Networking 2]]

Assignment 1 due

===February 5, 2018===

[[SystemsSec 2018W Lecture 9|Software Vulnerabilities 1]]

===February 7, 2018===
[[SystemsSec 2018W Lecture 10|Software Vulnerabilities 2]]

===February 14, 2018===

Assignment 2 due

===February 19 & 21, 2018===

Winter break, no classes

===February 26, 2018===

Mid-term review

===February 28, 2018===

Mid-term Exam

===March 19, 2018===

Assignment 3 due

===April 4, 2018===

Assignment 4 due

===April 9, 2018===

Last day of class