System sercurity desgin principles for computer security - design principles were originally geared towards operating systems but now they are for networks Topics of design 1 - simplicity of design - frugality and non essiential functionalities to be disabled by default - people often want only needed things 2 - Safe defaults - The use of safe defaults, and deny access but default(AKA whitelist) - Design services to be failsafe, if there is a failure then there is a safemode to counteract it 3 - Open designs - Dont rely on secret designs - encourage analysis, open review - But dont publish active security blueprints, it renders any security useless - Assume that an attacker can find out all of your secrets, design assuming that they are already known 4 - Complete mediation - For every access to every object, you want to verify proper credentials before access - User ID can be used, with each have its own sets of priviledges - Check that requests has intergrity, that access and requests do not change hands. Access goes to those that are approved 5 - isolated compartments - strong isolation structures prevent cross components contamination\ - "fire doesnt spread to the other parts" - like the use of a firewall - isolate resources, processes, users, accounts, - some can be shared but not everything 6 - least - priviledge - allocate programs and users as few prviledges as needed for the task that they need to do - aka adminastrator, sudo, roo, etc... 7 - modular design - avoid monolithic parts, GOD CODE - instead have oop and small grain units that provide more security 8 - small trusted bases - aim for small code sizes for trusted applications - stronger assurance for small code sizes - the smaller the design the easier it is to find errors and review it - small units of codes have more faith in cryptographic senses 9 - time tested tools - tools should be used that have been around for a long time - protocals, software tool kits, - new things often have more errors - standard metrics for a ccertain amount of errors in a 100, 1000 lines of code - you dont believe that there is any code outthere without any bugs - choose the one with more history and it often means less bugs - confidence in protocols and tool kits increase as the time of survival gets longer 10 - Principle of least suprise ---------------------------------------------------------------- - design UI, and software to behave as it is expected by a users mental model - users should be able to form and impression about how things work - how it is thought to work, should be how it works - dont want to allow people to form improper mental models, that lead to error 11 - User buy in ---------------------------------------------------------------- - designs are like to be used by you, and choices made by users should be correct (buy in) - you need to encourage the users to make the right decisions - for example, secrutiry with by passes, will not allow the user to trust that security is possible - Example, if you want a user to make a password with certain rules, you need to convince users that it is better your way - password strength bar, indicates to the user how passwords effect difficulty and security - opting into google's two step verification - dont make things too inconvient, or you would lose users. 12 - sufficient work factor ---------------------------------------------------------------- - design software that requires alot of work, that reduces the risk of others beating it too easily - bit coin mining requires lots of computation, which then reduces the incentive - amount of work imposed on someone may result in a lower incentive to hack 13 - defence in depth ---------------------------------------------------------------- - defences should be built in layers - example, castles have walls, moats, knights, - they have to defeat multiple layers to get to you - multiple independat defences, instead of building walls after walls. this is to ensure that they have to change methods to break through multiple layers - dont have weak spots in your defences, as attackers will simply target that. Have all defenses be equally defences 14 - evidence production ---------------------------------------------------------------- - have logs or records of activities to encourage accountability - to be able to reconstruct a scenerio - after the fact to use evidence to see what gone wrong - detction often defers attackers, just like cameras defer crimes 15 - data type verification ---------------------------------------------------------------- - data should be inspected and ensured that they perform only their duties - like your browser recieves static data, and then runs on your own machine - foriegn code is now running on your machine with data that is unknown to you and from where - example, posting to forums and then opening it on your browser, forum posts may have code that run on you machine (code injection) - you then have to sanitize it, to ensure that strings are strings, numbers are numbers, you need to do data type verification - an expectation of data should not become code 16 - remnant removal ---------------------------------------------------------------- - when a process terminates, then all data related to that process should be removed - ram, cache, secondary storage - this is why the cloud is risky, as no data is removed and always persistent - dropbox is an example of this. - your running a process, and quite often passwords will be moved around and stored everywhere. If this is stored in ram, and moved to a storage then you have a potietial security flaw 17 - trust anchor justification ---------------------------------------------------------------- - you should ensure any confidence put into any base points - example, in your browsers trusts of websites, they are certification public keys (trust anchors) - when you go on a site, you get sent a digital signature so that you can verify the certicifation to ensure that it is safe - certicates allow secure communication between you and the site - there are about 300 keys that each browser vendor places into you browser to allow you to securely access sites - this system is heavily relied on, but very brittle, when 1 key is comprimised... thousands of sites are then comprimised - they make a software change to blacklist the keys, and then the browsers update their keys - basically a drivers license to ensure that sites are legit, and the providers of these IDs have to do a good job to ensure secrutiy of their IDs(Keys) 18 - Independant confirmation ---------------------------------------------------------------- - If you want to install some software, how do you know youve found the right provider - Cryptographic hash, if your software and a trusted software have the same binary image - example, credit card companies call you when you make a big purchase 19 - Response integrity ---------------------------------------------------------------- - Dns reponse can often be fiddled with, not sure of reponse that were coming back were indeed the ip or dns that you were looking for - often there was no safeguard 20 - reluctant allocations ---------------------------------------------------------------- - be relunctant to allocate resources, espciecially when there is no authorization - example, you call a bank with a problem. and you think its the right number. BUT someone who calls you claiming to be the bank should be reluctantly conversed - requests from unknowns should be safeguarded, however requests from you to others should be safer. 21 - secure by design ---------------------------------------------------------------- - build secrutiy in the initial designs, because security often requires core design principles in early stages that are hard to add later on in the process - explicit state all secrutiy relatd assumptions4 22 - periodic reassessment ---------------------------------------------------------------- - always recheck sercurities as things evolve and change - Hard to change old previous software without oput breaking it