CISSP Week 13
- 1. Software Development Security CISSP Domain 4 Pages 632-698 Tim Jensen Lead Researcher StaridLabs
- 2. Software Development Methodolgy ● How to plan, design, scope, develop, and document an application or addition to an application.
- 3. Waterfall ● Slow – every phase is thoroughly planned and locked in before development beings. ● Developers work on one phase at a time, adhoc or concurrent tasks are generally not done. ● Better for security since code changes are thought out in advance and lack of concurrent tasks means your not 'mashing' code together. ● Once the design is approved there's no changing it if defects are found later. Once the product is released then a new cycle starts to plan, remediate, and add features.
- 4. Models based on Waterfall
- 5. Structured Programming Development ● Widely known ● Focuses on coherence, comprehensibility, freedom from faults, and security ● Requires defined processes and modular development ● Each phase requires review and approval
- 6. Spiral Method ● Each phase goes through the waterfall design phase ● Adds a risk assessment to 'check' phase. The estimated cost to complete the phase and the schedule are updated each iteration Based on the risk assessment a 'go or no go' decision is made.
- 7. Spiral Method 2 - PDCA
- 8. Cleanroom ● Significant time is spent in the design phase. ● Theory is bugs won't get into software if it's properly written the first time. ● Less time spent on testing of this 'perfect code'
- 10. Iterative Development ● Allows for refinement during the process ● Requires consistent change control – even during initial design ● Scope creep allowed ● Difficult to verify security due to constant changes
- 12. Types of Iterative Development
- 13. Prototyping ● Create a simplified version of the application and release it for review. Use the feedback to build a second, better version. ● Repeat process until users are satisfied ● Concept, design, implement, refine
- 14. Modified Prototype Model (MPM) ● Ideal for web app development ● Basic functionality is rapidly deployed ● Maintenance phase beings after deployment ● Flexibility and speed is key
- 15. Rapid Application Development ● Strict time limits are set for each phase ● Uses tools for rapid development ● Must watch for bad decisions that lead to poor design
- 16. Joint Analysis Development (JAD) ● Work directly with users to develop working application ● End users are directly involved with development planning and testing
- 17. Exploratory model ● System requirements are assumed. When further information comes in then the system is modified.
- 19. Other Models
- 20. Computer Aided Software Engineering (CASE) ● Uses tools and applications to rapidly develop and test functionality ● IDE, Test macros, fuzzers, Auto documentation functions, etc.
- 21. Computer-based development ● Uses standardized building blocks to assemble an application (vs develop) ● IE: Dreamweaver over a text editor for building a website.
- 22. Databases
- 23. Purpose of a database ● Central storage location ● saves disk space ● makes data more consistent
- 24. DBMS components ● Database engine ● Hardware Platform ● Application Software ● Users
- 25. Database Required Functions ● Transaction Persistence – The state of the database is the same after a transaction as it was prior. ● Fault tolerance and recovery – Data should remain in it's original state. ● Rollback recovery – Stripping transactions to a known good state ● Shadow recovery – Installing a known good state and adding transactions from a transaction log
- 26. Required Functions 2 ● Sharing by multiple users ● Data should be accessible to multiple users without locking or endagering the data ● Security Controls ● Access controls, integrity checking, etc
- 27. Relational Databases ● Use Primary keys and foreign keys to break data into tables of like data, allowing for table data to be linked. - Used to speed up queries of large sets of data
- 28. Structured Query Language (SQL) ● Allows for querying and displaying of data from a database ● SQL compliant databases have: ● Schemas – Describes structure of the database ● Tables – Columns and rows of data ● Views – Custom joins on data so multiple tables can be seen as one record
- 29. Database interface languages ● ODBC – Open Database Connectivity ● JDBC – Java Database Connectivity ● XML – Extensible Markup Language ● OLE DB – Object Linking and Embedding Database ● ADO – ActiveX Data Objects
- 30. ODBC ● Very common ● Username and password are stored in plaintext ● Call and return data are sent cleartext over the network ● Access verification is rudimentary ● ODBC drivers can elevate system access – applications must be trusted
- 31. JDBC ● Need to specify user authentication, control user access, and audit user functions. None of this is enabled by default.
- 32. XML ● Provides consistent strucutre to data ● Easy to transfer data between languages, operating systems, etc. ● **Rant on schemas
- 33. OLE DB ● Microsoft technology – not usable anywhere else. ● Allows documents or files to be embedded inside others. Example: A word document can be entirely embedded in an excel spreadsheet
- 34. Metadata ● Data about data – IE: headers on IP packets showing where the data came from and where it's going. ● Allows unrelated data to be correlated
- 35. Database threats ● Aggregation – combining nonsensitive data from separate sources to create sensitive information ● Bypass attacks – Users bypasses front end controls to access information ● Compromising database views ● Concurrency – Running processes that use old data, updates that are inconsistent, deadlocks ● Data Contamination – Data corruption ● Deadlocking – To users try to access the same information and both are denied
- 36. Threats Continued ● Denial of Service – Table locks, intensive processing, poor queries. ● Improper modification of information – Intensional or accidental modification of information which damages the integrity ● Inference – Users may be able to infer confidential information from available records ● Interception of data – Data may be intercepted between client and server
- 37. More Threats ● Query Attacks – Querying the database in a way that gains a user more information than if they used the trusted frontend ● Server Access ● Website security ● Unauthorized Access
- 38. Lock Controls ● Atomicity – A transaction is either fully committed or rolled back. No partial updates ● Consistency – Data must be validated before the transaction is allowed ● Isolation – Transaction is isolated from all other transactions until complete ● Durability – Completed transactions are permanent and will survive system/media failure (IE not stored in memory which is wiped if the power goes out – rather is stored on disk)
- 39. Web Application Threats ● Injection ● Broken Authentication and Session Management ● Cross-Site Scripting (XSS) ● Insecure Direct Object References ● Security Misconfiguration ● Sensitive Data Exposure ● Missing Function Level Access Control ● Cross-Site Request Forgery (CSRF) ● Using Components with Known Vulnerabilities ● Unvalidated Redirects and Forwards
- 40. Object Oriented Programming (OOP) ● Object oriented programming is ultimately writing applications in small blocks and connecting the blocks to create a functional system. ● This allows for code re-use, and security and portability of smiliar code. IE: All authentication code can be in one class and inherit permissions as a set.
- 41. OOP Things to know ● Encapsulation (Data Hiding) ● A class defines only the data I needs to be concerned with. The code cannot access other non-related data ● Good for security
- 42. Inheritance ● Subclasses can inherit properties of it's main class. Objects in the class can inherit from like objects
- 43. Polymorphism ● Objects may be processed differently depending on their data type. Instantiating an object from a prior object ensures the new object inherits attributes and methods from the original
- 44. Polyinstantiation ● Specific objects instantiated form a higher class may vary their behavior depending upon the data they contain ● Basically allows data classification programatically so data leakage/inference is minimized.
- 45. OOP Security ● No object should be able to access another object's internal data. Data should be passed in and out and while inside the object should be protected from external influence.
- 46. Class Inheritance ● Classes are designed to inherit code from other classes. This is a complex processes which in larger applications can cause security breaches for object access. ● Example: If there's administrator functions that require login credentials and someone can modify the code to allow access to the admin functions without credentials, then this would violate the access control model of the application.
- 47. What's so complex about class inheritance?
- 48. CORBA ● Jem already gave a mini talk on CORBA. If anyone has further questions related to CORBA security we can have Jem address them since I've never used CORBA.