Software Security

Which security approach should you use

A- test security mecanisms vs their policies. - verifies software features are working -includes security features, such as authentication and encryption B- simulating the attackers approach. -verifies applications resistance to attack -based on risks -tests with a adversarial mindset.

Passing a software penetration test assures that the software has no vulnerabilities.

False

Vulnerbality

Software defect that attackers can exploit

Black Box

Examines the system as a attacker would. and used to evaluate the effort required to attack the system.

static code analysis

Analysis of source code carried out without execution of that software. identifys vulnerabilities Can reduce testing efforts Lead to higher quality software Tools •Using tools, developers can analyze their source code •Scan the code and automatically detect errors that pass through compiler, but can be problems later •Some tools generate reports with graphical analysis results and recommend possible solutions Can generate false positives.

Syntax

Can be found by a compiler. It is the "English" of the code. For example the code could be missing a semicolon or a constant is misspelled.

Security Technologies

Cryptography -securing communication and storage in software systems Access Control -for threats related to misbehaving users in software systems Language Based security -for threats related to misbehaving programs

Complete mediation

Every access to every object must be checked for authority

Limitations about penetration testing

If pen testing is the only method used it is not sufficient. Ad-hoc pen testing= lack of metrics and standardization

Least common mechanism

In systems with multiple users, mechanisms allowing resources to be shared by more than one user should be minimized.

Common vulnerabilities to be exploited

Incorrect or complete input validation Poor or missing exception handling Buffer overflows SQL injection Race conditions

Risk Sources

Infrastructure Weakness -networks and internet -cryptosystems -access control, authentication, usability -Complexity of software system -extensibility of software system.

Psychological acceptability

It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly

Goals of software security

Know your own and your enemy -You should secure vulnerabilities-threats-risks. Secure software from attackers, external, internal, insider activities Prevent risks and threats through design. -exploit the bad design/implementation Traceability and Auditing provide deterrence -auditing is essential for software security.

Two main categories of software defects

Logical Syntax

Buffer overflows

Method to exploit software by remotely injecting code to a targeted application If the program is using more memory than it has a overflow can happen and overwrite the next chunk of memory.

White Box

Most efficient technique, the tester knows all about the system including source code, design, requirements

Bugs

Programming errors introduced during software implementation -buffer overflows, race conditions, unsafe system calls, incorrect validation •Discovering and eliminating bugs during code analysis will roughly take care of half of the problems when tackling software security •Common attack patterns need to be considered during de-bugging

Code Analysis

Review of software for malicious signatures Defects have two categories Bugs Flows

Incorrect or complete input validation

The parameter input can cause problems, if no validation exists the following attacks can occur: -cross-site scripting -illegal pointer values -integer overflows -DNS's cache poisoning Good approach to validation is to use a whitelist.

Fail-safe defaults

The principle that when a system fails, the default failure state will be a safe state by design. the default is deny of access

Separation of privilege

This principle dictates that multiple conditions should be required to achieve access to restricted resources or have a program perform some action.

Types of Security Testing

White Box Black Box Grey Box

Software Bugs

a defect in a program that keeps it from performing as it should Main causes -complexity of features -ignorance of developers

Grey Box

applies both white box and black box techniques.

Least Privilege

default to no access. should only have the rights to complete your duties.

Which step should security be considered

every step in the SDLC

Logical-

hard to find and fix, if the code has proper syntax but returns a different output than expected it is most likely a logical defect

An SQL injections occurs because of

improper input validation

SQL Injection

o Attackers take advantage of invalidated input to pass SQL commands for execution in a database. o Attackers use SQL commands with parameters provides by the user, so they embed the SQL commands inside the parameters o Can exploit SQL queries to access controls, authentication and authorization checks.

Race conditions

o Cause the timing of events to be affected when scheduling dependencies among multiple threads are not appropriately synchronized o Can have a negative outcome on security if a sequence of events is needed between the two events, but a race happens and the sequence is not ensured by a program. Three categories of race § Infinite loops- causes the program to never end § Deadlocks- occur if the program is waiting on a resource without a timeout mechanism, and the resource is never released § Resource collisions- represent failures to synchronize access to shared resources. This results in resource corruption or privilege escalations.

Open Design

the design of a security mechanism should be open rather than secret •The design should be open for scrutiny by the community.

Most attacks occur because a hacker takes advantage of:

vulnerability in the software

In _____________________ testing, the tester has access to the source code.

white box

Penetration Testing

you test software in a deployed environment by attacking it and exploiting vulnerabilities. most common method used. most commonly misused does not give assurance if you pass a pen test

List the least secure programming languages

· C · PHP · Java · Javascript · Python · C++ · Ruby

List 3 common software vulnerabilities

• Incorrect or incomplete input validation • Poor or missing exception handling • Buffer overflows • SQL injection • Race conditions

List at least three security design principles that should be used in secure software design.

• Least privilege • Economy of mechanism • Complete mediation • Open design • Separation of privilege • Least common mechanism • Psychological acceptability • Fail-safe defaults

What cant static analysis detect

•Automatically identify common coding problems • •Only for Implementation bugs by developer's error • •Can not identify design and architectural flaws • •Can not identify poorly designed cryptographic libraries or improperly selected algorithms • •Can not identify design problems • •Cannot identify passwords or numbers embedded in code • •Prone to produce false positives when potential vulnerabilities no not exist • •

Two common software security practices

•Business invests less in application security strategy, design, and code review services •Security flaws are identified only at the later stages of the application lifecycle. •High cost to fix •High maintenance cost

Source Code Reviews

•Can integrate code review in the software development process Code reviewers •Meet with developers • •Determine it the code meets the secure code development criteria • •Should consider coding standards and code review checklists • •Inspect code comments, documentation, unit test plans, security requirements •Unit test plans •Should include how to test the code • •Should demonstrate that the code meets security requirements and design/coding standards to reduce design flows and implementation bugs • •Should include a test procedure, inputs, and expected outputs

Security Design principles

•Least privilege •Economy of mechanism •Complete mediation •Open design •Separation of privilege •Least common mechanism •Psychological acceptability •Fail-safe defaults

Flows

•Problem at a much deeper level •More subtle •Originated from its design and being instantiated in code •compartmentalization problems in design, error-handling problems, and broken or illogical access control

Security Testing vs Standard Testing

•Secure software testing adds a focused adversary •Standard software testing focus on software failure Security testing is different from penetration testing as you use risk analysis to build tests, and measure security against risk mode.

Example Threats and mitigation techniques.

•Spoofing Identity •Compromise authentication •protect keys & passwords, .. . •Tampering with Data •Compromise integrity •access control, hashes, digital signatures, MACs (message authentication codes), write-once storage... •Repudiation •logging, audit trails, digital signatures, ... •Information Disclosure •Compromise confidentiality •access control, encryption, not storing secrets, ... •Denial of Service •Compromise availability •graceful degradation, filtering, increase server resources •Elevation of Privilege •access control, sandboxing, ...

Economy of mechanisms

•Sufficiently small and simple as to be verified and implemented. •If the mechanism is simple, then it is less possible to go wrong. •When error occurs, it is easier to figure out what caused the error and how to fix it.

What can static analysis tools detect

•Syntax problems •Unreachable code •Unconditional branches into loops •Undeclared variables •Uninitialized variables •Parameter type mismatches •Uncalled functions and procedures •Variables used before initialization •Non-usage of function results •Possible array bound errors