SP_slides_2.pptx

Secure Programming Information Security Basic Review  C.I.A?  Confidentiality, Integrity, and Availability  Components of an Information Systems?  Hardware, Sofware, Data, People, Procedures, Networks  ICT  (Information and...

Secure Programming Information Security Basic Review  C.I.A?  Confidentiality, Integrity, and Availability  Components of an Information Systems?  Hardware, Sofware, Data, People, Procedures, Networks  ICT  (Information and Communication Technologies) refers to technologies that provide access to information through telecommunications.  ICT security  is the set of products, services, organization rules and individual behaviors that protect the ICT system of a company. Secure Programming 2 Basic Problems  low problem understanding (awareness)  mistakes of human beings (especially when overloaded, stressed, …)  human beings have a natural tendency to trust  complex interfaces / architectures can mislead the user and originate erroneous behaviors  performance decrease due to the application of security  ask for the (involuntary) user’s participation to the attack action  usually naive users are targeted (e.g. “do change immediately your password with the following one, because your PC is under attack”)...  but experienced users are targeted too (e.g. by copying an authentic mail but changing its Secure Programming attachment or URL) 3 Roots of Insecurity  “Defensive strategies are reactionary”  “Thousands - perhaps millions - of system with weak security are connected to the Internet”  “The explosion in use of the Internet is straining our scarse technical talent. The average level of system administrators has decreased dramatically in the last 5 years”  “Increasingly complex software is being written by programmers who have no training in writing secure code” Secure Programming 4 Attacks  An attack is the deliberate act that exploits vulnerability  It is accomplished by a threat-agent to damage or steal an organization’s information or physical asset  A vulnerability is an identified weakness of a controlled system whose controls are not present or are no longer effective  An exploit is a technique to compromise a system  An attack is then the use of an exploit to achieve the compromise of a controlled system Secure Programming 5 Some classes of attacks  Phishing (~ fishing):  “dear Internet banking user, please fill in the attached module and return it to us ASAP according to the privacy law 675 …”  Psychological pressure:  “help me, otherwise I’ll be in troubles …”  “do it, or I’ll report it to your boss …”  showing acquaintance with the company’s procedures, habits and personnel helps in gaining trust and make the target lower his defenses Secure Programming 6 Some classes of attacks  Back Doors  Using a known or previously unknown and newly discovered access mechanism, an attacker can gain access to a system or network resource  Password Crack  Attempting to reverse calculate a password  Brute Force  The application of computing and network resources to try every possible combination of options of a password  Dictionary  The dictionary password attack narrows the field by selecting specific accounts to attack and uses a list of commonly used passwords Secure Programming (the dictionary) to guide guesses 7 Some classes of attacks  IP spoofing / shadow server  someone takes the place of a (legitimate) host  Packet sniffing  passwords and/or sensitive data are read by (unauthorized) third parties  Connection hijacking / data spoofing  data inserted / modified during their transmission  Denial-of-service (distributed DoS)  the functionality of a service is limited or disrupted (e.g. ping bombing) Secure Programming 8 Risk estimation  Assets: Objects, data, people  Vulnerability: Weakness of an asset  Threat: loss of security due to vulnerability  Attack: threat occurrence  Risk estimation is the process of identifying vulnerabilities and threats and their impact and probability of occurring an attack. Secure Programming 9 Security Design Principles Principal of ….  Least Privilege  Separation of privilege  Fail-safe defaults  Complete mediation  Economy of mechanism  Least Common Mechanism  Psychological acceptability Secure Programming 10 Principle of least privilege  Provide bare minimum privileges to a program or user to function properly  Temporary elevation should be relinquished immediately  Granularity of privileges Advantage  Abuse of privileges is restricted  Damage caused by the compromised user or application is reduced Secure Programming 11 Separation of Privilege  Access should not be granted based on single condition  Multiple conditions should be required to achieve access to restricted resources Examples:  Two persons to sign a bank cheque  Password login + OTC to perform financial transactions Secure Programming 12 Fail-safe defaults  The default configuration of a system should have a conservative approach…  Default access to an object is none  Explicit access to an object should be given Examples  Access Control Lists  Firewall rules Secure Programming 13 Complete mediation  Instead of one-time check, every access to a resource must be checked for compliance with a protection scheme  restricts the caching of information  Security vs performance issue  Whenever a subject attempts to read an object, the operating system should mediate the action. First, it determines if the subject can read the object. If so, it provides the resources for the read to occur. If the subject tries to read the object again, the system should again check that the subject can still read the object. Most systems would not make the second check. They would cache the results of the first check, and base the second access upon the cached results. Secure Programming  UNIX file descriptor 14 Principle of economy of mechanism  Simplicity in design and implementation of security measures  A simple secure framework provides…  Fewer errors  Development, testing and verification of security measures is easy  Less assumptions Secure Programming 15 Least common mechanism  In shared systems with multiple users, mechanisms allowing resources to be shared by more than one user should be minimized  Separate channel for users  Separation of network resources Secure Programming 16 Principle of psychological acceptability  Security mechanism should not make the resources difficult to access  User interface should be well designed and intuitive  Security related setting should consider the expectation of ordinary users Secure Programming 17