Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | jonah-morton |
View: | 220 times |
Download: | 3 times |
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