ISEC0511 Programming for Information System Security

1. ISEC0511Programming for Information System Security Lecture Notes #4 Security in Software Systems (cont)

2. Safe Programming • A safe program will be able to protect unknown attacks, as against security that is designed for known attacks. • You can define security programming as protecting your assets from known external threats. • In safe programming, you protect your assets from unknown internal threats, like from another program or the OS. • In safe programming, you ensure that your program cannot be used by a hacker to attack someone else’s asset.

3. Safe Programming for Network Applications • For networking applications, you implement all the following functions as described for business applications. • In addition, it needs to look at the socket interfaces. • check that all data packets passed to your program are clean and their type, length, and value are exactly as expected. • Any deviation must be caught as an exception. • Any output from your application must also be clean, and any data that are of unknown type must not go out. Network Application

4. Safe Programming for Business Applications • Use perimeter security that will include firewalls, IDS, IPS, antivirus, honeypot, and malware catcher systems. • Ensure that the application is developed using a security development lifecycle with minimum attack surface. • There should be no known security bug in the application, and no unsafe function calls or methods should be used in the program. • Ensure that all data input to the program, all input from files, and all external methods are clean. • This is achieved through the validation of input data for type, length, and value.

5. Safe Programming for Business Applications Application Software Library Operating System (OS)

6. Security Review • During the security development lifecycle, you need to always keep in mind the pitfalls in the program that an attacker would attempt to exploit. • Code review can be in the following steps: • Step 1. Identify security code review objectives • Step 2. Perform a preliminary scan • Step 3. Review code security issues • Step 4. Review for security issues unique to the architecture

7. Security Review • To perform the review, you need a team. • Team members should have the knowledge of security vulnerabilities and security requirements. • They should also know where to look for vulnerabilities.

8. 1. Identify security code review objectives • You should know the security issues that are common for any application as well as any specific code changes that should be reviewed. • Input/data validation • Authentication • Authorization • Accounting

9. 1. Identify security code review objectives • Journaling • Sensitive data • Performance-critical code • Safety-critical portion in the code • Exception management • Data access • Cryptography

10. 1. Identify security code review objectives • Unsafe and unmanaged code use • Code injection • Cross-site scripting • Configuration • Threading • Undocumented public interfaces • Privilege management and elevated privilege

11. 2. Perform Preliminary Scan • Perform static analysis and segment the code in regions to find an initial set of security issues. • Automatic scan. Use a tool if available. • Manual scan. Whether you use a tool or not, a manual scan is always advised.

12. 2. Perform Preliminary Scan • Review team should review the code with following questions in mind: • Define trust boundaries • Input data validation • Code that authenticates users • Code that authorizes users • Cryptography

13. 2. Perform Preliminary Scan • Error handling code • Complex code • Privilege elevation • Performance and safety-critical code • Access native code • External libraries • RPC (Remote Procedure Call)

14. 3. Review Code for Security Issues • In this step, you manually review the code to find security vulnerabilities. • There are several criteria where you should look for: • Trust boundaries • Input and output • Code characteristics

15. Trust Boundaries • Assess how much you trust each input source. • Place high trust in the following: • Input generated by code inside the component • Input generated by trusted sources • Inputs coming from known, good, strongly named, managed packages, or trusted native libraries • Input from a database that is generated only by your component and that contains data which you can prove to be properly validated • Network data that is encrypted and digitally signed by a trusted source

16. Trust Boundaries • Place medium trust in the following: • Input from known assemblies or libraries that have not been certified to be trusted, but are local to your server • Input from public interfaces that are accessible by trusted users • Input from a user interface component that is accessible by trusted users • Network data that is not accessible by an untrusted user, such as the internal LAN

17. Trust Boundaries • Place low trust in the following: • Input that comes from a client • Input that comes over the network • Input that comes from foreign assemblies or libraries that have not been certified as trusted • Input that comes from a file • Input that comes from a public interface that is accessible to any user • Any input that cannot be considered to be medium or high trusted • Code that has been downloaded from the Internet

18. Input and output • Focus on data that flow through: • User interface • Database interaction • Public interfaces • Socket interaction • File I/O • Pipes (send data between applications)

19. Code characteristics • Code with the following characteristics should be examined: • Old code • Code that runs in elevated context • Anonymously accessible code • Code that runs by default • Code listening on a globally accessible network interface • Code written in C/C++ and assembly language • Copy–paste code • Dead code

20. Code characteristics • Code written in scripting languages • Code that handles sensitive data • Code that changes frequently or carries a history of vulnerability • Complex code • Spaghetti code. Code that has been modified over and over again. • Code that uses high level of compiler optimization

21. Other security risks • Trapdoors/Backdoors • Logic Bombs

22. 4. Review for security issues unique to the architecture • Looking for security issues that relate to the unique architecture of your application.

23. Generating the Executable • When you are done with the code review, the next step is to compile the code. • Tools for Checking Code • Lint. • Tool in UNIX analyzed the static code and detects possible or likely errors in C/C++ code. • PREfast • This is a tool from Microsoft to do static checks on source code. • PREfast detects common basic coding errors in C and C++ programs.

24. Generating the Executable • FxCop • This is a code analysis tool in the Microsoft platform that checks .NET managed code. • AppVerif • AppVerif is an application verifier tool for Microsoft platforms for unmanaged non-.NET code. • You may search for other tools on the Internet too.

25. Security Testing • Every piece of software needs to be tested before it is used in the production environment. • You should test whether the software is doing what it is expected to do. • You also need to test whether the software is doing something that it is not expected to do.

26. Vulnerability Assessment • The process of vulnerability assessment is to conduct various analyses and tests on a particular system to assess presence of security vulnerabilities. • External Vulnerability Assessments • Internal Vulnerability Assessments • Vulnerability Assessments Tools

27. External Vulnerability Assessments • This group of assessments determines the presence of security vulnerability in the system when used from external environments such as some external network or untrusted environment, especially from the Internet.

28. Internal Vulnerability Assessments • This group of assessments is conducted from inside of the corporate network, LAN, or the trusted network. • It shows what a disgruntled employee or an individual within the trusted zone can accomplish.

29. Vulnerability Assessments Tools • Many tools can be used for analyzing systems and identifying vulnerabilities. • Many of them are free and open domain tools. • Web site sectools.org contains information about many security testing tools. For example: • Nessus, wireshark, snort, netcat, hping2, kismet, tcpdump, cain and abel, john the ripper, ettercap, nikto, paros, dsniff, …

30. Code Coverage Tools • This is a type of tool that can verify the runtime code and tell you whether you have covered the code during testing. • Coverage may focus only on critical code. • Some free tools are available on the Internet.

31. Penetration Testing • In a penetration test, you try to penetrate into the system by breaking the security of the system. • A penetration test also helps us to understand the peripheral security of an organization. • It helps assess vulnerabilities of a security deployment. • A penetration test mainly looks at the network security.

32. Ethical Hacking • In many literatures, ethical hacking and penetration testing are used interchangeably. • In ethical hacking, the person who is testing the system is a hacker but not hacking the system for malicious purpose. • In penetration testing, an expert tester can use some of the penetrating testing tools and test the security vulnerability. • Both of them can be considered security testing. • Ethical hackers may use some of the standard tools, but mainly they will write • proprietary custom tools that will try to hack the system to discover vulnerabilities.

33. Fuzz Testing • Fuzz testing or Fuzzing is a technique for software testing that provides random data (fuzz) to the inputs of a program. • If the program fails, the defects can be noted. • The advantage of fuzz testing is that the test design is simple and free of preconceptions about system behavior.

34. Fuzz Testing • The input for fuzz testing is random. • This is sometimes called black box testing. • For the command-line fuzz tests, the random input was simply random ASCII character streams. • For X-Window fuzz tests, Windows NT fuzz tests, and Mac OS X fuzz tests, the random input included cases that had only valid keyboard and mouse events.

35. Fuzz Testing • If the application crashes or hangs, it is considered to fail the test; otherwise it passes. • In fuzz testing, it is accepted that the system may not respond in a sensible manner or even quietly exit. • Fuzz testing can be automated to a high degree and results can be compared across applications, operating systems, and vendors. • Reference: http://www.cs.wisc.edu/~bart/fuzz/

36. Secured Deployment • To protect your assets, you must have multiple lines of defense. • The first line of defense is the perimeter security. • A secured and safe system will be the second line of defense. Perimeter Security Secure and Safe System

37. Secured Deployment • Some perimeter security mechanism • Firewall services • IPS/IDS services • Malware capture services, e.g. honeypot • Application proxy services • Antivirus • Port scan detectors

38. gpg --verify *-CHECKSUM gpg --verify *-CHECKSUM Secured Deployment • Suspicious activities that can be detected by perimeter security • DoS attack • Virus • Port scans • Access to unwanted services • Access to unnecessary services • Access to unwanted TCP/IP ports

39. Readings • Architecting Secure Software Systems, Chapter 2.