SystemsSec 2018W Lecture 10: Difference between revisions
Created page with "==Audio== [https://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec10-07Feb2018.m4a Lecture 10 Audio]" |
|||
(One intermediate revision by one other user not shown) | |||
Line 2: | Line 2: | ||
[https://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec10-07Feb2018.m4a Lecture 10 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''' |
Latest revision as of 06:32, 1 March 2018
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