This document discusses various software development methodologies and their security implications: - Waterfall model is slow but more secure since changes are planned in advance. Iterative models are faster but less secure due to constant changes. - Structured programming, spiral model, cleanroom, and iterative development approaches are described. Iterative development requires strong change control. - Prototyping, rapid application development, and joint analysis development are types of iterative development. - Databases must provide transaction persistence, fault tolerance, access controls, and prevent inference and aggregation attacks. Object-oriented programming improves code reuse and security through encapsulation, inheritance, and polymorphism. Web applications are vulnerable to injection, authentication failures,

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'

9. Iterative Development

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.