Application and Website Security 101

crookpatedspongySoftware and s/w Development

Dec 2, 2013 (3 years and 7 months ago)

67 views

Application and Website
Security 101

Daniel Owens

IT Security Professional

Agenda

Course Introduction

Secure Software Development Lifecycle

Common Vulnerabilities And Mistakes

Conclusion And Appendices

Communication Media and Security
Concerns

Communication media:

‘Wired’ networks

‘Wireless’ networks

Security concerns:

The Insider

The Outsider

The Technology

Nature

Consequences of Poor Security

Stolen intellectual property

System downtime

Lost productivity

Damage
to
reputation

Lost

public confidence

Lost revenue

Congressional inquiries

Challenges When Implementing
Security

Attacker needs to only “know” one vulnerability

Defender needs to secure
all

entry points

Attacker has unlimited time

Defender works with time and cost constraints

Attackers vs. Defenders

Security vs. Usability

Overly/Improperly secured systems can be more difficult to use

Complex and strong passwords can be difficult to remember

Users prefer simple passwords

Do I need

security…

Security As an Afterthought

Many developers and management think that security does not add
any value and is negative to the user’s experience

Addressing vulnerabilities just before or after a product is released is
very expensive

The Developer Role in Security

Developers must:

Work with

clients, program managers, designers,
testers, architects,
and systems administrators to
ensure security

Work with specialists who are knowledgeable
concerning application and website security

Contribute to security by:

Adopting good

security
development practices

Knowing where security vulnerabilities occur and how to
avoid them

Using secure programming
techniques

Communicate heavily with peers and users

Agenda

Course Introduction

Secure Software Development Life
cycl
e

Common Vulnerabilities And Mistakes

Conclusion And Appendices

Secure Software Development
Lifecycle

Requirements Phase

Application Program Manager must take the
initiative and document the following (in concert
with the client):

What the application MUST be able to do

What kind of data the application is to hold/process
(e.g.
SSNs

and health information)

The security requirements to be followed

Any legal requirements the application MUST follow


Requirements Phase (cont.)

Examples:

Client Application PM must also dictate:

Developer training requirements

Testing requirements/secure coding requirements

Developer security controls regarding the source
code

Any requirements incumbent upon the client (e.g.
Computer Security Act of 1987 and E
-
Government
Act of 2002)

Any additional requirements (e.g. L&F, acceptable
languages, environment)

Architecture Phase

Application Program Managers must take the
initiative and document the following (in concert
with the client):

The operating
system(s
) upon which the application
is to operate

Operating System constraints

Memory constraints

Processing power constraints

The network environment

Any other operational/architectural constraints and
requirements

Design Phase

During the design phase, the Design Team
should document the following:

The
language(s
) to be used

Coding Standards and Guidelines

The third party modules, libraries to be used

How to secure data

Data types, naming schemas, etc

These should detail
HOW

to accomplish the
requirements while not exceeding the
constraints and should be carefully examined

Implementation Phase

The Development Team should ensure that the
code:

Follows the Coding Standards and Guidelines

Follows the design documentation

Does not allow a violation of the Byzantine Generals
Problem

Is well
-
written; methodically written; and adheres to
all requirements, protocols, standards and best
practices that are applicable for the system

Is SAFE and SECURE

Test Phase

The Test Team should ensure that the system:

Never enters an unstable or unknown state

Is free from input validation, logic, and other flaws

Provides the appropriate levels of assurance for
confidentiality, integrity, and availability

Maintains adequate code coverage statistics

Adheres to the requirements set forth in the
previous phases

Deployment Phase

The Release Manager and Application
Administrator should ensure that:

The source code and binaries are fully protected

The software is distributed with appropriate security
guidance

The software is installed in accordance with all
appropriate security guidance

The software is operated in a secure manner

Agenda

Course Introduction

Secure Software Development Lifecycle

Common Vulnerabilities And Mistakes

Conclusion And Appendices

Common Vulnerabilities

* Often Cited As Two Major Areas:


Design


Implementation

* But A Third Major Area Exists:


Architecture

* Other Areas:


Requirements


Deployment


Testing



Design Flaws

Design flaws often require significant redesign
and redevelopment to resolve

Example Design Flaws

Weak encryption or using encoding instead of
encryption

Requires choosing a new encryption algorithm and can
require a slew of changes… especially in a client
-
server
model

Weak access control

Often requires a complete redesign of both the
authentication mechanisms and most of the modules to
accommodate the new access control

Design Flaws (cont.)

Example Design Flaws (cont.)

Overexposed resources

May require a complete redesign of the entire system

Incomplete input validation mechanisms or
algorithms

Will likely require modifications in several places

Incomplete threat modeling

May require a complete redesign of the entire system

Math flaws, bad assumptions, etc.

May require a complete redesign of the entire system


Design Flaws (cont.)

Example Design Flaws (cont.)

Poor adherence to secure design principles

May require a complete redesign of the entire system and
significant code rewrites

Poor adherence to multi
-
threading or multi
-
processing design principles

May be extremely difficult to reproduce, track down, and
then eliminate

Poor adherence to requirements and architecture
documents

May require a complete redesign of the entire system and
significant code rewrites


Design Flaws (cont.)

Example Design Flaws (cont.)

Choosing the wrong language

May make implementation difficult, extremely buggy,
break the time or space requirements set forth by the
architecture documents, or result in code that is difficult
to manage

Implementation Flaws

Implementation flaws may be hard to track
down in large projects and may require
substantial modifications to the source code

Example Implementation Flaws

Poor adherence to multi
-
threading or multi
-
processing development principles

May be extremely difficult to reproduce, track down, and
then eliminate

Poor adherence to change management principles

Violates the Byzantine Generals Problem


Implementation Flaws (cont.)

Example Implementation Flaws (cont.)

Poor adherence to the client
-
server principles

May produce software that doesn’t operate with other
software, is more buggy, or is more vulnerable to attack

Poor adherence to the requirements, architecture,
and design phase documentation

May make the software unusable and require a complete
rewrite of major portions of the code

Programming errors, misunderstandings, math
errors, etc

Can be simple to correct, but can also be numerous


Architecture Flaws

Architecture flaws normally don’t become
obvious until either during testing or once the
system has been deployed, so they can become
both embarrassing and impossible to get
passed

Example Architecture Flaws

Poor understanding of the requirements

If not caught soon enough, the system may not recover

Poorly architected hardware

This can doom a system

Requirements Flaws

Requirements flaws, like architecture flaws
occur in the beginning of the cycle, so impact
the most phases in the cycle; if not caught early,
these can be expensive to fix

Example Requirements Flaws

Neglecting to spell out client requirements

If the client’s requirements aren’t well known, the system
cannot be properly constructed

Neglecting to spell out functional requirements

If these requirements aren’t properly dictated, the system
will most likely be missing desired functionality

Requirements Flaws (cont.)

Example Requirements Flaws (cont.)

Neglecting to spell out testing
activities/requirements

The software may not be tested in accordance with client
requirements or not properly/fully tested

Neglecting to spell out security requirements

The software may have additional vulnerabilities

Neglecting to spell out protocols and relationships
between
interprocessing

units

Can make the software unusable in a parallel processing
or client
-
server environment (or heterogeneous
environment)


Deployment Flaws

Deployment flaws may be the result of poor
requirements or architecture, they may also be
because of design flaws or implementation
flaws, but often require a knowledge of the
system to detect/remediate

Example Deployment Flaws

Poor adherence to secure installation and operation
guidance

If none is available, it must be created, otherwise it may
be easy to fix unless this is required because of a bug in
the software

Deployment Flaws (cont.)

Example Deployment Flaws (cont.)

Insecure defaults

Requiring a slew of changes to make a system more
secure means that some changes may be missed or
simply not made

Enabling debugging or compiling with debugging
flags

This provides an attacker with more information than the
attacker needs to have

Poor change management

Can doom a system

Testing Flaws

Testing flaws allow immature code to be put
into production environments, putting the
production environment at risk

Example Implementation Flaws

Failure to follow the requirements and test for
adherence to the requirements

The tests may not be valid or may miss key bugs and
requirements that were not adhered to

Failure to have complete code coverage

Without complete code coverage, there could be many
simple bugs that were missed

Testing Flaws (cont.)

Example Testing Flaws (cont.)

Failure to test for security vulnerabilities

Allows security vulnerabilities to go unnoticed

Failure to perform tests in a realistic environment

The tests are only valid for the environment in which it the
tests are performed

Failure to properly report problems

If they aren’t properly reported, they are difficult to fix

Failure to perform regression testing and verify fixes

Can lead to incorrect assumptions of correctness

Session Summary

Course Introduction

Secure Software Development Lifecycle

Common Vulnerabilities And Mistakes

Conclusion And Appendices


For More Information

Microsoft Security Site (all audiences)

http://www.microsoft.com/security


MSDN Security Site (developers)

http://msdn.microsoft.com/security

Common Weakness Enumeration (CWE)
(developers)

http://cwe.mitre.org/top25/index.html

Most Common Software Errors

http://discussweb.com/software
-
testing/803
-
most
-
common
-
software
-
errors.html