Application and Website Security 101

Daniel OwensIT Security Professional

Agenda

Course IntroductionSecure Software Development LifecycleCommon Vulnerabilities And MistakesConclusion And Appendices

Communication Media and Security Concerns

Communication media:‘Wired’ networks‘Wireless’ networks

Security concerns:The InsiderThe OutsiderThe TechnologyNature

Consequences of Poor Security

Stolen intellectual propertySystem downtimeLost productivityDamage to reputationLost public confidenceLost revenueCongressional inquiries

Challenges When Implementing Security

Attacker needs to only “know” one vulnerabilityDefender needs to secure all entry pointsAttacker has unlimited timeDefender works with time and cost constraints

Attackers vs. Defenders

Security vs. Usability

Overly/Improperly secured systems can be more difficult to useComplex and strong passwords can be difficult to rememberUsers prefer simple passwords

Do I needsecurity…

Security As an Afterthought

Many developers and management think that security does not add any value and is negative to the user’s experienceAddressing 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 securityWork with specialists who are knowledgeable concerning application and website securityContribute to security by:

Adopting good security development practicesKnowing where security vulnerabilities occur and how to avoid themUsing secure programming techniquesCommunicate heavily with peers and users

Agenda

Course IntroductionSecure Software Development LifecycleCommon Vulnerabilities And MistakesConclusion 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 doWhat kind of data the application is to hold/process (e.g. SSNs and health information)The security requirements to be followedAny legal requirements the application MUST follow

Requirements Phase (cont.)

Examples:Client Application PM must also dictate:Developer training requirementsTesting requirements/secure coding requirementsDeveloper security controls regarding the source codeAny 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 operateOperating System constraintsMemory constraintsProcessing power constraintsThe network environmentAny other operational/architectural constraints and requirements

Design Phase

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

The language(s) to be usedCoding Standards and GuidelinesThe third party modules, libraries to be usedHow to secure dataData 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 GuidelinesFollows the design documentationDoes not allow a violation of the Byzantine Generals ProblemIs well-written; methodically written; and adheres to all requirements, protocols, standards and best practices that are applicable for the systemIs SAFE and SECURE

Test Phase

The Test Team should ensure that the system:

Never enters an unstable or unknown stateIs free from input validation, logic, and other flawsProvides the appropriate levels of assurance for confidentiality, integrity, and availabilityMaintains adequate code coverage statisticsAdheres 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 protectedThe software is distributed with appropriate security guidanceThe software is installed in accordance with all appropriate security guidanceThe software is operated in a secure manner

Agenda

Course IntroductionSecure Software Development LifecycleCommon Vulnerabilities And MistakesConclusion And Appendices

Common Vulnerabilities

* Often Cited As Two Major Areas:DesignImplementation

* But A Third Major Area Exists:• Architecture

* Other Areas:RequirementsDeploymentTesting

Design Flaws

Design flaws often require significant redesign and redevelopment to resolveExample 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 controlOften 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 modelingMay 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 codeExample 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 passedExample Architecture Flaws

Poor understanding of the requirementsIf not caught soon enough, the system may not recover

Poorly architected hardwareThis 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 fixExample Requirements Flaws

Neglecting to spell out client requirementsIf 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/remediateExample 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 managementCan doom a system

Testing Flaws

Testing flaws allow immature code to be put into production environments, putting the production environment at riskExample 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 coverageWithout 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 problemsIf 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 IntroductionSecure Software Development LifecycleCommon Vulnerabilities And MistakesConclusion 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 Errorshttp://discussweb.com/software-testing/803-most-common-software-errors.html