1

ISEC0511Programming for Information

System Security

Lecture Notes #4Security in Software Systems

(cont)

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.

2

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.

3

Network ApplicationNetwork Application

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.

4

Safe Programming for Business Applications

5

Application

Software Library

Operating System (OS)Operating System (OS)

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

6

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.

7

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

8

1. Identify security code review objectives

Journaling Sensitive data Performance-critical code Safety-critical portion in the code Exception management Data access Cryptography

9

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

10

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.

11

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

12

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)

13

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

14

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

15

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

16

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

17

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)

18

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

19

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

20

Other security risks

Trapdoors/Backdoors Logic Bombs

21

4. Review for security issues unique to the architecture

Looking for security issues that relate to the unique architecture of your application.

22

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.

23

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.

24

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.

25

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

26

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.

27

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.

28

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, …

29

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.

30

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.

31

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.

32

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.

33

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.

34

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/

35

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.

36

Perimeter Security

Secure and Safe System

Secured Deployment

Some perimeter security mechanism Firewall services IPS/IDS services Malware capture services, e.g.

honeypot Application proxy services Antivirus Port scan detectors

37

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

38

-- -*gpg verify CHECKSUM -- -*gpg verify CHECKSUM

Readings

Architecting Secure Software Systems, Chapter 2.

39