Application and Website Security 101

1. Application and Website Security 101 Daniel Owens IT Security Professional

2. Agenda • Course Introduction • Secure Software Development Lifecycle • Common Vulnerabilities And Mistakes • Conclusion And Appendices

3. Communication Media and Security Concerns • Communication media: • ‘Wired’ networks • ‘Wireless’ networks • Security concerns: • The Insider • The Outsider • The Technology • Nature

4. Consequences of Poor Security • Stolen intellectual property • System downtime • Lost productivity • Damage to reputation • Lost public confidence • Lost revenue • Congressional inquiries

5. 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 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 user’s experience Addressing vulnerabilities just before or after a product is released is very expensive Security As an Afterthought Challenges When Implementing Security

6. 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

7. Agenda • Course Introduction • Secure Software Development Lifecycle • Common Vulnerabilities And Mistakes • Conclusion And Appendices

8. Secure Software Development Lifecycle

9. 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

10. 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)

11. 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

12. 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

13. 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

14. 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

15. 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

16. Agenda • Course Introduction • Secure Software Development Lifecycle • Common Vulnerabilities And Mistakes • Conclusion And Appendices

17. Common Vulnerabilities * Often Cited As Two Major Areas: Design Implementation * But A Third Major Area Exists: • Architecture * Other Areas: Requirements Deployment Testing

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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)

27. 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

28. 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

29. 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

30. 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

31. Session Summary • Course Introduction • Secure Software Development Lifecycle • Common Vulnerabilities And Mistakes • Conclusion And Appendices

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