aws.101 cleaned

7/28/2019 Aws.101 Cleaned

1/32

Application and WebsiteSecurity 101

Daniel Owens

IT Security Professional


2/32

Agenda

Course Introduction

Secure Software Development Lifecycle

Common Vulnerabilities And MistakesConclusion And Appendices


3/32

Communication Media and Security

Concerns

Communication media:

Wired networks

Wireless networks

Security concerns:

The Insider

The Outsider

The Technology

Nature


4/32

Consequences of Poor Security

Stolen intellectual property

System downtime

Lost productivityDamage to reputation

Lost public confidence

Lost revenueCongressional inquiries


5/32

Challenges When Implementing

SecurityAttacker needs to only know one vulnerabilityDefender needs to secure all entry points

Attacker has unlimited time

Defender works with time and cost constraintsAttackers 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 addany value and is negative to the users experience

Addressing vulnerabilities just before or after a product is released is

very expensive


6/32

The Developer Role in Security

Developers must:Work with clients, program managers, designers,testers, architects, and systems administrators toensure security

Work with specialists who are knowledgeableconcerning application and website security

Contribute to security by:

Adopting good security development practices

Knowing where security vulnerabilities occur and howto avoid them

Using secure programming techniques

Communicate heavily with peers and users


7/32

Agenda

Course Introduction


Common Vulnerabilities And MistakesConclusion And Appendices


8/32

Secure Software Development

Lifecycle


9/32

Requirements Phase

Application Program Manager must take theinitiative and document the following (inconcert with the client):

What the application MUST be able to doWhat kind of data the application is tohold/process (e.g. SSNs and health information)

The security requirements to be followedAny legal requirements the application MUSTfollow


10/32

Requirements Phase (cont.)

Examples:

Client Application PM must also dictate:

Developer training requirements

Testing requirements/secure coding requirements

Developer security controls regarding the sourcecode

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)


11/32

Architecture Phase

Application Program Managers must take theinitiative and document the following (inconcert with the client):

The operating system(s) upon which theapplication is to operate

Operating System constraints

Memory constraintsProcessing power constraints

The network environment

Any other operational/architectural constraintsand requirements


12/32

Design Phase

During the design phase, the Design Teamshould 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 therequirements while not exceeding the

constraints and should be carefully examined


13/32

Implementation Phase

The Development Team should ensure thatthe code:

Follows the Coding Standards and Guidelines

Follows the design documentation

Does not allow a violation of the ByzantineGenerals Problem

Is well-written; methodically written; and adheresto all requirements, protocols, standards and bestpractices that are applicable for the system

Is SAFE and SECURE


14/32

Test Phase

The Test Team should ensure that thesystem:

Never enters an unstable or unknown state

Is free from input validation, logic, and other flaws

Provides the appropriate levels of assurance forconfidentiality, integrity, and availability

Maintains adequate code coverage statisticsAdheres to the requirements set forth in theprevious phases


15/32

Deployment Phase

The Release Manager and ApplicationAdministrator should ensure that:

The source code and binaries are fully protected

The software is distributed with appropriatesecurity guidance

The software is installed in accordance with allappropriate security guidance

The software is operated in a secure manner


16/32

Agenda

Course Introduction


Common Vulnerabilities And Mistakes

Conclusion And Appendices


17/32

Common Vulnerabilities

* Often Cited As Two Major Areas:

Design

Implementation

* But A Third Major Area Exists:

Architecture

* Other Areas:

Requirements

Deployment

Testing


18/32

Design Flaws

Design flaws often require significantredesign and redevelopment to resolve

Example Design Flaws

Weak encryption or using encoding instead ofencryption

Requires choosing a new encryption algorithm and canrequire a slew of changes especially in a client-

server model

Weak access control

Often requires a complete redesign of both theauthentication mechanisms and most of the modules to

accommodate the new access control


19/32

Design Flaws (cont.)

Example Design Flaws (cont.)

Overexposed resources

May require a complete redesign of the entire system

Incomplete input validation mechanisms oralgorithms

Will likely require modifications in several places

Incomplete threat modelingMay require a complete redesign of the entire system

Math flaws, bad assumptions, etc.



20/32



Poor adherence to secure design principles


and significant code rewritesPoor 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 architecturedocuments


and significant code rewrites


21/32



Choosing the wrong language

May make implementation difficult, extremely buggy,

break the time or space requirements set forth by thearchitecture documents, or result in code that is difficultto manage


22/32

Implementation Flaws

Implementation flaws may be hard to trackdown in large projects and may requiresubstantial modifications to the source code

Example Implementation FlawsPoor adherence to multi-threading or multi-processing development principles

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

Poor adherence to change managementprinciples

Violates the Byzantine Generals Problem


23/32

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 toattack

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

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

Programming errors, misunderstandings, matherrors, etc

Can be simple to correct, but can also be numerous


24/32

Architecture Flaws

Architecture flaws normally dont becomeobvious until either during testing or once thesystem has been deployed, so they can

become both embarrassing and impossible toget passed

Example Architecture Flaws

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

Poorly architected hardware

This can doom a system


25/32

Requirements Flaws

Requirements flaws, like architecture flawsoccur in the beginning of the cycle, so impactthe most phases in the cycle; if not caught

early, these can be expensive to fixExample Requirements Flaws

Neglecting to spell out client requirements

If the clients requirements arent well known, thesystem 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


26/32


27/32

Deployment Flaws

Deployment flaws may be the result of poorrequirements or architecture, they may alsobe because of design flaws or implementation

flaws, but often require a knowledge of thesystem to detect/remediate

Example Deployment Flaws

Poor adherence to secure installation andoperation guidance

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


28/32

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 orsimply not made

Enabling debugging or compiling with debuggingflags

This provides an attacker with more information thanthe attacker needs to have

Poor change management

Can doom a system


29/32

Testing Flaws

Testing flaws allow immature code to be putinto production environments, putting theproduction environment at risk

Example Implementation FlawsFailure to follow the requirements and test foradherence to the requirements

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

Failure to have complete code coverage

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


30/32

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 environmentThe tests are only valid for the environment in which itthe tests are performed

Failure to properly report problems

If they arent properly reported, they are difficult to fix

Failure to perform regression testing and verifyfixes

Can lead to incorrect assumptions of correctness


31/32

Session Summary

Course Introduction


Common Vulnerabilities And Mistakes

Conclusion And Appendices


32/32

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
http://www.microsoft.com/securityhttp://msdn.microsoft.com/securityhttp://cwe.mitre.org/top25/index.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://discussweb.com/software-testing/803-most-common-software-errors.htmlhttp://cwe.mitre.org/top25/index.htmlhttp://msdn.microsoft.com/securityhttp://www.microsoft.com/securityhttp://www.microsoft.com/security

aws.101 cleaned

Documents