Principles of Internetbased Applications Network Principles to consider

Principles of Internet-based Applications • Network – Principles to consider because application uses a network • Security Design – Principles to consider when designing your Internet-based app CSC 445 Networks & Secure Software Development 1

Principles: Network • Does application need to run on different types of hosts? – When app is web-based: • Should not matter which web server software is used – This may be hard to do • Should not matter which web browser software is used – This should be easy to do – When app is not web-based: • Use development environment that deploys to many platforms, if possible – Possible when deploying to desktop environments – Mobile environments have not reached this level of maturity CSC 445 Networks & Secure Software Development 2

Principles: Network (cont’d) • Application architecture can leverage – Internet architecture • Which transport layer protocol should be used? – TCP for connection-oriented – UDP for connectionless • Which network layer protocol should be used? – IP (i. e. , we’ll address confidentiality in app layer protocol) – IPsec protocol suite (i. e. , to add another layer of defense) – WWW architecture • Use built-in client-server architecture by using HTTP or HTTPS? – Note: App does not need to use a web browser to use HTTP or HTTPS CSC 445 Networks & Secure Software Development 3

Principles: Network (cont’d) • Processes communicate with each other; programs do not – Process communication done using sockets • Using sockets simply means learning an API • Otherwise, similar to file I/O – Identify process you want to communicate with • Need IP address and a port number • What’s a port number? – A software concept that allows many types of protocols to be sent/received over same physical connections – A process must request use of a port number – OS provides services (e. g. , buffers) for process to use CSC 445 Networks & Secure Software Development 4

Principles: Network (cont’d) • Use existing application-layer protocol – e. g. , HTTPS, FTP, SMTP OR • Develop new application-layer protocol 1. Identify types of messages exchanged • e. g. , request messages, response messages 2. Define syntax of each message type • e. g. , fields in each message, how fields are delineated 3. Define semantics of each message type • e. g. , how is data validated; what does data mean 4. Define rules for when and how a process sends messages and responds to messages CSC 445 Networks & Secure Software Development 5

Principles: Network (cont’d) • What network services does application need? – Reliable data transfer • Is loss of data okay for app? – Yes, use UDP (e. g. , audio/video) – No, use TCP (e. g. , ftp, financial apps, e-mail) – Bandwidth • Does app require a minimum bandwidth? – Yes (e. g. , telephony, audio/video) – No (e. g. , ftp, e-mail) – Timing • How much end-to-end delay can the app experience? – i. e. , applicable to interactive real-time apps CSC 445 Networks & Secure Software Development 6

Internet Protocol Stack & Security Layers: Application Transport Network Link Physical Confidentiality Mi. DC No No Integrity Mi. DC No No Availability Maybe No Non-repudiation Mi. DC No No Assurance Mi. DC No No Authenticity Mi. DC No No Anonymity Maybe Yes Yes Mi. DC – Mostly, if Designed Correctly! CSC 445 Networks & Secure Software Development 7

Network Security Goals (CIA) Fundamental Concepts • Confidentiality • Assurance – Avoiding unauthorized disclosure of information • Integrity – Information has been altered only in authorized way • Availability – Information is accessible and modifiable in a timely fashion by authorized entities – How trust is provided and managed in computer systems • Policies, permissions, and protections • Authenticity – Ability to determine that statements, policies, and permissions issued by persons or systems are genuine • Anonymity – A property that certain records or transactions are not attributable to any individual • Non-repudiation CSC 445 Networks & Secure Software Development – User responsible for their actions and should not be able to deny what they have done 8

Principles: Security Design (Introduction) • Fifteen security principles! – First ten come from paper written in 1975!! • by Saltzer and Schroeder – In 2013, five more principles were added • by Gary Mc. Graw CSC 445 Networks & Secure Software Development 9

Principles: Security Design (All 15) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Economy of mechanism Fail-safe defaults Complete mediation Open design Separation of privilege Least common mechanism Psychological acceptability Work factor Compromise recording CSC 445 Networks & Secure Software Development 11. 12. 13. 14. 15. Secure the weakest link Defend in depth Be reluctant to trust Promote privacy Use your resources 10

Principles: Security Design (1 through 3) 1. Economy of mechanism – Keep your design as simple as possible • Allows quality assurance methods the greatest chance of finding security vulnerabilities 2. Fail-safe defaults – Default setting/action should be to favor security over usability • When in doubt, deny access 3. Complete mediation – Every request to access data/system should be checked for adherence to a protection scheme • Strike a balance with performance (e. g. , speed, power usage) and usability requirements CSC 445 Networks & Secure Software Development 11

Principles: Security Design (4 through 7) 4. Open design – Publish your design for anyone to review • No one person is an expert in all things security-related! 5. Separation of privilege – Separate components of a system to reduce damage when a security breach occurs in any one component 6. Least privilege – Each user and program should operate with minimum set of privileges necessary to accomplish the job • Every user should not have “admin” rights 7. Least common mechanism – Minimize security mechanisms being shared/used by more than one user or system CSC 445 Networks & Secure Software Development 12

Principles: Security Design (8 through 11) 8. Psychological acceptability – User interfaces related to security mechanisms should be designed based on what a user expects 9. Work factor – Cost of compromising a security mechanism should be compared with the resources of an attacker when designing a security scheme 10. Compromise recording – It may be more desirable to record the details of an intrusion rather than designing more sophisticated prevention mechanisms 11. Secure the weakest link – Suite of security mechanisms being used are only as good as the weakest security mechanism being used CSC 445 Networks & Secure Software Development 13

Principles: Security Design (12 through 15) 12. Defend in depth – Your design should include redundancy and layers of defense 13. Be reluctant to trust – Be skeptical of security protections that are not within your software system (i. e. , trust but verify) 14. Promote privacy – Your design needs to consider types of personal information you are collecting from a user • Do you really need to persistently store this data? • Do you really need to send this data over a network? 15. Use your resources – Talk to others about design choices you are making – Have experts with different backgrounds review your design CSC 445 Networks & Secure Software Development 14

• Wow, this is a lot to take in! CSC 445 Networks & Secure Software Development 15