Transcript ISEC0511

ISEC0511
Programming for Information
System Security
Lecture Notes #4
Security in Software Systems
(cont)
1
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
2
attack someone else’s asset.
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
3
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
Application
Software Library
Operating System (OS)
5
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


AppVerif


This is a code analysis tool in the Microsoft
platform that checks .NET managed code.
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.
Perimeter Security
Secure and Safe
System
36
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
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
38
Readings

Architecting Secure Software Systems,
Chapter 2.
39