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

Attackers vs. Defenders

Defender works with time and cost constraints Overly/Improperly secured systems can be more difficult to use Complex and strong passwords can be difficult to remember Users prefer simple passwords

Security vs. Usability

Do I need security

Many developers and management think that security does not add any value and is negative to the users experience Addressing vulnerabilities just before or after a product is released is very expensive

Security As an Afterthought

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 Lifecycle 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 EGovernment 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 Requirements Deployment Testing

* Other Areas:

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 clientserver 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 multiprocessing 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 multiprocessing 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 doesnt 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 dont 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 clients requirements arent well known, the system cannot be properly constructed

Neglecting to spell out functional requirements

If these requirements arent 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 arent 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-mostcommon-software-errors.html