Software Development Security
Software Development Security CISSP Domain 8 Mind Map
1. Web Security
1.1. Specific Threats for Web Environments
1.1.1. Administrative Interfaces
1.1.1.1. If the administrative interface be on Web it must be very secure
1.1.1.1.1. Remember the password panels is a bad idea
1.1.1.2. Use of SSH is a good alternative
1.1.2. Authentication and Access Control
1.1.3. Input Validation
1.1.3.1. Path or Directory Traversal
1.1.3.1.1. Using../ to the root in a URL
1.1.3.2. Unicode Encoding
1.1.3.2.1. Achieving ../ with the Unicode characters like %c1%1c etc.
1.1.3.3. URL Encoding
1.1.3.3.1. Putting encoding of root access code with different encoding into URL
1.1.3.4. Client side validation
1.1.3.4.1. Like a form when you are reminded with empty spaces, takes place before it goes to server
1.1.3.5. XSS Attacks
1.1.3.5.1. Non persistent XSS Vulnerabilities
1.1.3.5.2. Persistent XSS Vulnerabilities
1.1.3.5.3. DOM (Document Object Model)
1.1.4. Parameter Validation
1.1.4.1. Like input validation
1.1.4.1.1. Checking if the input is within the limits
1.1.4.2. Pre-Validation
1.1.4.2.1. Checking in the client side
1.1.4.3. Post-Validation
1.1.4.3.1. In the server
1.1.4.4. If sensitive info is placed into “hidden fields” in a web page, it can be exploited by using a web proxy like burp suite
1.1.5. Session Management
2. Software Development Methodologies
2.1. Waterfall Methodology
2.1.1. Each phase needs to be configured from moving on
2.1.2. A review at the end of each phase, whether to continue
2.1.3. OK for small projects, have scalability issues
2.2. V-Shaped Methodology
2.2.1. Rigid like Waterfall, no concurrency, no iterations, no risk analysis
2.2.2. The dif from WF -> not a linear flat approach like WF, has testing in design in all phases
2.3. Prototyping
2.3.1. Creating a sample model or code and from that understand the usability and design problems and adjust
2.3.2. 3 types of prototype models
2.3.2.1. Rapid Prototype
2.3.2.1.1. Quick model to see, not to be build upon, its quick and dirty
2.3.2.2. Evolutionary Prototype
2.3.2.2.1. It’s to be build upon, with incremental improvement it becomes the final product, lab environment
2.3.2.3. Operational Prototype
2.3.2.3.1. It’s like evolutionary but it’s grown into the prod environment.
2.4. Incremental Methodology
2.4.1. Working software in early stages and incremental working pieces in other iterations
2.4.2. Like a multi waterfall
2.5. Spiral Methodology
2.5.1. Emphasis on risk analysis
2.5.2. Four main phases
2.5.2.1. Determine Objectives
2.5.2.2. Risk Analysis
2.5.2.3. Development and Test
2.5.2.4. Plan the next Iteration
2.5.3. Iterations makes it granular and new security issues be covered
2.5.4. Good for complex projects w/ fluid requirements
2.6. Rapid Application Development
2.6.1. Prototypes and iterative processes
2.6.2. Data and process models are refined through the process
2.6.3. Puts value in pace
2.6.4. Makes client involved so their needs are mapped in functionality
2.7. Agile Methodologies
2.7.1. User Stories
2.7.1.1. What a user wants to do and why
2.7.2. Flexible in the methods the teams are going to employ
2.7.3. Types
2.7.3.1. Scrum
2.7.3.1.1. Lean
2.7.3.1.2. Customer focused
2.7.3.1.3. Team collaboration
2.7.3.1.4. Customer Involvement
2.7.3.1.5. Continuous Delivery
2.7.3.1.6. Sprints
2.7.3.2. Extreme Programming
2.7.3.2.1. Take away Scrums regularity and add lots of code reviewing
2.7.3.2.2. Pair programming
2.7.3.2.3. Test driven development
2.7.3.3. Kanban
2.7.3.3.1. Production scaling, emphasis on on-time delivery
2.7.3.3.2. Production Phases
2.8. Other Methodologies
2.8.1. Exploratory Methodology
2.8.1.1. Employable in areas where objectives are not clearly defined
2.8.2. Joint Application Development (JAD)
2.8.2.1. Workshop oriented w/ the inclusion of subject matter experts, end users etc.
2.8.3. Reuse Methodology
2.8.3.1. Gradually modifying pre existing code
2.8.4. Cleanroom
2.8.4.1. Prevent any errors
2.8.4.2. Formal methods
2.8.4.3. Highly critical processes
2.8.4.4. For apps to be put through strict certification processes
2.9. Integrated Product Team
2.9.1. Multidisciplinary Approach from tester, quality control to accountants
2.9.2. It’s a management technique
2.9.3. JAD works well with it
2.9.3.1. JAD is more focused on involving user community
2.9.3.2. IPT is inward facing, business stakeholders
2.10. DevOps
2.10.1. Integrating Development, IT, Quality Assurance (QA)
2.10.2. Has a huge impact on security because of the divesity
3. Capability Maturity Model Integration (CMMI)
3.1. Provides best practices, procedures, practices for institutions to be able to develop SDLC methodologies
3.1.1. Which are repeatable, of high quality, continuous improvement
3.2. 3rd party companies evaluate sw dev companies to certify their processes
3.3. Five maturity levels of CMMI
3.3.1. Initial
3.3.1.1. No assurance of consistency
3.3.1.2. Quality is unpredictable
3.3.2. Repeatable
3.3.2.1. Process is characterized for projects and repeatable
3.3.3. Defined
3.3.3.1. Characterized for organization and proactive
3.3.4. Managed
3.3.4.1. Process quantitatively measured and controlled
3.3.5. Optimizing
3.3.5.1. Focuses on Continuous Process Improvement
3.4. W/ prototyping methodology probably in CMMI 1 especially if their practices are ad-hoc
3.5. CMM is the predecessor of CMMI
3.6. Other Maturity Models
3.6.1. DevOps Maturity Model
3.6.1.1. How effective is the DevOps practices
3.6.1.2. Involves culture and people evaluation
3.6.2. Open Source Maturity Model (OSMM)
3.6.2.1. For organizations who use Open Source, how involved or participating are they in the community
3.6.3. Software Product Management Maturity Model
3.6.3.1. Focuses on business issues that surrounds SD
4. Change Management
4.1. Change Control
4.1.1. Change in prod code never should be come from the programmer, but from the librarian
4.1.2. Code should be developed, tested and sent to the librarian
4.1.3. A process for dealing with changes should be put into place at the beginning of a project to avoid scope creep.
4.1.4. Change control processes should be evaluated in system audits.
4.1.5. After changes
4.1.5.1. If changes are significant, the functionality and level of protection needs to be evaluated -> certified
4.1.5.2. Management would have to approve the overall system -> accreditation
5. Secure Coding
5.1. Source Code Vulnerabilities
5.1.1. OWASP Top 10 List
5.2. Secure Coding Practices
5.2.1. Carnegie Mellon University SEI Top 10 Practices
5.2.1.1. Validate Inputs
5.2.1.2. Heed Compile Warnings
5.2.1.2.1. Mind them, system must enforce it
5.2.1.3. Architect and Design for Security Policies
5.2.1.4. Keep It Simple
5.2.1.4.1. Ensured through regular code reviews
5.2.1.5. Default Deny
5.2.1.6. Adhere to the Principle Of Least Privilege
5.2.1.7. Sanitize Data Sent to Other Systems
5.2.1.8. Practice Defense in Depth
5.2.1.9. Use Effective Quality Assurance Techniques
5.2.1.9.1. Free of defects and Vulnerabilities
5.2.1.10. Adopt a Secure Coding Standard
5.2.2. ISO/IEC 27034
6. Database Management
6.1. Database Management Software
6.1.1. DBMS
6.1.1.1. Transaction Persistence
6.1.1.1.1. Integrity of the Data
6.1.1.1.2. Security in all states
6.2. Database Models
6.2.1. Relational
6.2.1.1. AttributesxTuples
6.2.1.2. Form of tables
6.2.1.3. Primary Key
6.2.2. Hierarchical
6.2.2.1. Tree Structure
6.2.2.1.1. Can have branches and leaves like sub parts and data fields or not
6.2.2.1.2. No indexes
6.2.2.1.3. Parent/child relationship
6.2.2.2. LDAP
6.2.3. Network
6.2.3.1. The Network Database Model
6.2.3.1.1. A child’s can have multiple parents
6.2.3.1.2. Not related to networks as in Chapter 4
6.2.3.1.3. Like mesh network topology - only by attributes
6.2.4. Object-Oriented
6.2.4.1. More dynamic than relational
6.2.4.2. Handles a variety of data like audio video etc
6.2.5. Object-Relational
6.2.5.1. It’s a relational database with a front-end written in OO Language
6.2.5.2. So systems can use the front end to process data, so devices with limited processing power can use the DB
6.3. Database Programming Interfaces
6.3.1. Open Database Connectivity (ODBC)
6.3.1.1. An API that allows an application to communicate with a database.
6.3.2. Object Linking and Embedding Database (OLE DB)
6.3.2.1. COM based - Microsoft prop
6.3.2.2. Works as middleware that the apps can use
6.3.2.3. Extends usability of ODBC
6.3.2.4. Access through ActiveX Data Objects (ADO)
6.3.3. ActiveX Data Objects (ADO)
6.3.3.1. Uses OLE DB to create connections
6.3.3.2. Can be developed with many different scripting languages
6.3.3.3. Commonly used in web applications
6.3.3.4. A high level data access interface to a low level one like OLE DB
6.3.3.5. A set of COM objects
6.3.3.6. SQL commands are not necessary when accessing with ADO
6.3.4. Java Database Connectivity (JDBC)
6.3.4.1. Same functionality as ODBC but specifically for by Java DB apps
6.3.4.2. DB independent connectivity btw a Java platform and a variety of DBs
6.3.4.3. A Java API that allows Java programs to run SQL statements
6.4. Relational Database Components
6.4.1. Data Definition Language (DDL)
6.4.1.1. Schema
6.4.2. Data Manipulation Language (DML)
6.4.2.1. View, add, modify, sort
6.4.3. Query Language (QL)
6.4.3.1. Making requests
6.4.4. Report Generator
6.4.4.1. Printouts
6.4.5. Data Dictionary
6.4.5.1. To centrally manage Metadata
6.4.5.2. Data element definitions, schema objects etc
6.4.5.3. Authorization controls
6.5. Integrity
6.5.1. Concurrency
6.5.1.1. Locking a table, view, row, or a field
6.5.2. Semantic Integrity
6.5.2.1. Uniqueness constrains
6.5.2.2. Logical controls
6.5.2.3. Data types
6.5.3. Referential Integrity
6.5.3.1. All foreign keys reference to a valid and existing primary key
6.5.4. Entity Integrity
6.5.4.1. Primary keys must be unique and every tulle must contains exactly one
6.5.5. Operations
6.5.5.1. Rollback
6.5.5.1.1. Cancel the current transaction and turn back to the original
6.5.5.2. Commit
6.5.5.2.1. A transaction occurs only if its full and successful
6.5.5.3. Savepoint
6.5.5.3.1. Having too many can reduce performance so a balance is needed
6.5.5.4. Checkpoint
6.5.5.4.1. Saves when a certain amount of memory fills up
6.5.5.5. Two-phase commit
6.6. Database Security Issues
6.6.1. Aggregation
6.6.1.1. A user does not have the clearance to access an information, but has the permission to access the components of that application
6.6.1.1.1. Aggregating small allowed pieces to find out the unalloyed info
6.6.1.2. To mitigate, place components in containers in a higher level
6.6.2. Inference
6.6.2.1. Intended result of aggregation
6.6.2.1.1. Data at a lower level portrays data in a higher level
6.6.2.2. Other Mitigation Tactics
6.6.2.2.1. Cell suppression
6.6.2.2.2. Partitioning
6.6.2.2.3. Noise and perturbation
6.6.2.3. Database Views
6.6.2.3.1. They can be used as a logical access control
6.6.2.3.2. Can be used with MAC or DAC
6.6.2.3.3. With views you can hide some info from someone while presenting that to someone else all from the same table
6.6.2.4. Polyinstantiation
6.6.2.4.1. Using the same subject, making it look like they are performing another task
6.6.2.5. Online Transaction Processing (OLTP)
6.6.2.5.1. Fault tolerance and higher performance
6.6.2.5.2. OLTP watches for problems and rollbacks if necessary
6.6.2.5.3. Load balance capabilities, keeping track of DB performance
6.6.2.5.4. Synchronization btw DBs
6.6.2.5.5. Records transactions in real time
6.6.2.5.6. Characteristics of ACID Test
6.7. Data Warehousing and Data Mining
7. Distributed Computing
7.1. Register
7.1.1. In client server model register them to see where they are and what they do
7.2. Distributed Computing Environment (DCE)
7.2.1. A standard developed by Open Software Foundation (OSF) or the Open Group
7.2.2. Provides a Remote Procedure Call (RPC) service, security, directory, time, services and distributed file support
7.2.2.1. Time service provides host clock synchronization
7.2.2.2. Directory service called Universal Unique Identifier (UUID)
7.2.2.3. Thread service prioritizes threads
7.2.2.4. DFS sets up a virtual file system
7.2.2.5. Security service perform authentication and authorization
7.2.2.6. RPC is like the sum of them
7.2.2.6.1. Collects the commands and prepare them to transmit over the network
7.2.3. Network layer
7.2.4. A set of management services w/ a communications layer based on RPC
7.2.5. It sits on the network layer and provide services above it
7.2.6. Was the first attempt at standardizing heterogeneous system comm in a Client/Server Model
7.2.6.1. CORBA, DCOM, and J2EE followed it
7.3. Distributed Components Object Model (DCOM)
7.3.1. Like DCE
7.3.1.1. Relies heavily on DCE
7.3.2. Microsoft proprietary
7.3.3. Directory service called Globally Unique Identifier (GUID)
7.4. CORBA and ORBs
7.4.1. Common Object Request Broker Architecture (CORBA)
7.4.1.1. Open, object oriented, standard arch developed by Object Management Group (OMG)
7.4.1.2. Provides interoperability btw SW, HW, and platforms
7.4.1.3. Defines, APIs, Comm Protocol, C/S models to allow apps written in dşverse programming languages work together.
7.4.1.4. Main reason it works because it uses standardized interfaces. All programming languages use that.
7.4.1.5. Two main parts
7.4.1.5.1. System Oriented Components
7.4.1.5.2. Application Oriented Components
7.5. COM and DCOM
7.5.1. Component Object Model and Distributed COM
7.5.2. COM
7.5.2.1. Enables comm within one computer system
7.5.2.2. Microsoft proprietary
7.5.2.2.1. For an app to interact with the Windows, OR the apps developed for Windows, COM is required
7.5.3. DCOM
7.5.3.1. Support the same model for component interaction
7.5.3.2. Supports distributed inter process communication (IPC)
7.5.3.2.1. C/S system
7.5.3.2.2. Across networks
7.5.3.3. Works like ORB, like RPC, MOM, and ODBC
7.5.3.4. Replaced with .NET framework
7.6. Object Linking and Embedding
7.6.1. Linking
7.6.1.1. Being able to call another program, through a URL or sth.
7.6.2. Embedding
7.6.2.1. Being able to place objects on other programs
7.6.2.1.1. Like being able to place a picture on a Word document
7.6.3. If it works on WWW its called ActiveX
7.7. Java Platform, Enterprise Edition
7.7.1. Just like COM and CORBA, but for Java
7.8. Service-Oriented Architecture (SOA)
7.8.1. A web based approach
7.8.2. Uses service brokers
7.8.3. Services within SOA is usually provided through web services
7.8.3.1. Simple Object Access Protocol
7.8.3.1.1. An XML based protocol to exchange messages btw a requester and a web service provider
7.8.3.2. HTTP
7.8.3.3. Web Services Description Language (WSDL)
7.8.3.3.1. The list the UDDI presents
7.8.3.4. Universal Description, Discovery, and Integration
7.8.3.4.1. An XML based registry that lists available services
7.8.4. Mashup
7.8.4.1. Combination of functionality, data capabilities of more than one resources
7.8.4.1.1. Like a website present content from different websites
8. Building Good Code
8.1. Where to place security?
8.2. Various Environments and Security
8.3. Environment vs. Application
8.4. Functionality vs. Security
8.5. Implementation and Default Issues
8.5.1. Have no default security
8.5.1.1. NetBIOS
8.5.1.2. FTP
8.5.1.3. TFTP
8.5.1.3.1. Trivial File Transfer Protocol
8.5.1.4. SNMP
8.5.1.4.1. Simple Network Managemnt Protocol
9. SDLC
9.1. Project Management
9.1.1. Statement of Work (SoW)
9.1.1.1. Detailed expectations to avoid Scope Creep situations
9.1.2. Work Breakdown Structure (WBS)
9.1.2.1. Tasks and sub tasks of the SDLC with a clearly defined deliverables
9.2. Requirements Gathering Phase
9.2.1. Security Items on this Phase
9.2.1.1. Security Requirements
9.2.1.1.1. CIA to what degree of each.
9.2.1.2. Security Risk Assessment
9.2.1.3. Privacy Risk Assessment
9.2.1.3.1. P1
9.2.1.3.2. P2
9.2.1.3.3. P3
9.2.1.4. Risk-level Acceptance
9.3. Design Phase
9.3.1. Software Design
9.3.1.1. Informational Model
9.3.1.1.1. The type of info to be processed and how it’ll be processes
9.3.1.2. Functional Model
9.3.1.2.1. The tasks and function the app shall carry out
9.3.1.3. Behavioral Model
9.3.1.3.1. The state the application will be after certain transitions
9.3.1.4. These models are inputs into design the outputs ->
9.3.1.4.1. Data Design
9.3.1.4.2. Architectural
9.3.2. Security
9.3.2.1. Attack Surface Analysis
9.3.2.2. Threat Modeling
9.3.2.2.1. Threat Trees
9.4. Development Phase
9.4.1. Input Lengths against Buffer Overflow, No covert channels, checksums
9.4.1.1. Peer Review
9.4.1.2. Documentation
9.4.2. Automated CASE tools
9.4.2.1. IDEs etc.
9.4.3. Static Analysis
9.5. Testing Phase
9.5.1. Test Driven Development
9.5.1.1. Unit tests
9.5.1.1.1. Isolate a part of the SW and run w/ various inputs
9.5.1.2. Integration Testing
9.5.1.2.1. Components work together
9.5.1.3. Acceptance Testing
9.5.1.4. Regression Testing
9.5.1.4.1. After a change, retesting functionality, performance, and protection
9.5.2. Security Attacks, Pen-tests
9.5.3. Manual Testing and Dynamic Analysis
9.5.4. Back door or Maintenance Hook
9.5.4.1. Code that allows developers to login with a click, bypassing AC
9.5.4.1.1. Can be exploited
9.6. Operations and Maintenance Phase (O&M)
9.6.1. Verification vs. Validation
9.6.1.1. Verification
9.6.1.1.1. If the product accurately represents and meets the specifications
9.6.1.2. Validation
9.6.1.2.1. If it addresses the original question
9.6.2. Patches, zero day vulnerabilities, addressed issues, hot fixes etc.
9.6.2.1. Phase a CISSP most involved of
10. Mobile Code
10.1. Java Applets
10.1.1. Transmitted through web browsers
10.1.2. It’s a java program compiled to byte
10.1.3. After the client receives it JVM runs it in a sandbox
10.1.3.1. JVM mediates access to system resources
10.2. ActiveX Controls
10.2.1. Microsoft prop based on COM and DCOM
10.2.1.1. Microsoft no longer supports it in Edge
10.2.2. They are like windows DLLs (dynamic link libraries)
10.2.2.1. Once they are downloaded they become a part of the OS
10.2.2.1.1. Works in a privileged mode
10.2.3. Allows web browsers to execute other software application
10.2.3.1. Like opening a portable file document (PDF)
10.2.4. Component Container Feature
10.2.4.1. Allows applications to reuse and ActiveX
10.2.4.1.1. Exploited and patched many times
10.2.5. Unlike Java applets they are downloaded to hard drive and has greater access
10.2.5.1. Provides security levels and authentication settings.
10.2.5.1.1. Asks to user whether to download it or not.
10.2.6. Uses authenticode and relies on digital certificates
11. Security of Development Environments
11.1. The Development Platforms
11.1.1. IDE’s
11.1.2. Configuration of endpoints, workstations
11.1.3. Provisioning the Development clients and servers
11.1.4. Place prod and dev environments on separate VLANs.
11.2. The Code Repositories
11.2.1. Employing the code securely from development to prod is a challenge
11.2.1.1. The most secure way is to isolate them and carry the code in btw with removable storage media
11.2.1.1.1. Not scalable
11.2.1.2. Host the repo in the Intranet
11.2.1.2.1. Require the use of SSH
11.2.1.3. Use Web based repository service providers
11.2.1.3.1. Not enough for big corporations and projects
11.3. Software Configurations
11.3.1. Service Configuration Management
11.3.1.1. Concurrency
11.3.1.1.1. Multiple people extract the same file from a repo and make independent changes - SCM deals - built in in repos
11.3.1.2. Versioning
11.3.1.2.1. Keeping track of file revisions
11.3.1.2.2. Roll-back capability
11.3.1.3. Synchronization
11.3.1.3.1. Keeping up w/ the changes other people make on a file you extracted
12. Programming Languages and Concepts
12.1. Assemblers, Compilers, Interpreters
12.1.1. Assemblers
12.1.1.1. Assembly code into machine code
12.1.2. Compilers
12.1.3. Interpreters
12.1.3.1. .NET Environments
12.1.3.1.1. First translated into an intermediate, platform independent format - Common Intermediate Language (CIL)
12.1.3.2. Java
12.1.3.2.1. Source code compiled into an intermediate called Bytecode
12.1.3.2.2. Garbage collection, memory management, validating address usage,etc.
12.1.4. Security Issues Specific to Programming Languages
12.1.4.1. C
12.1.4.1.1. Buffer Overrun Error
12.1.4.1.2. Format String Error
12.1.5. Garbage Collection
12.1.5.1. C doesn’t have it Java has
12.1.5.2. Garbage Collector
12.1.5.2.1. Frees parts of memory that were once allocated but not in use any longer
12.2. Object-Oriented Concepts
12.2.1. Encapsulation
12.2.1.1. Data hiding
12.2.1.1.1. No object is allowed to access to another objects internal data or processes
12.2.2. Object
12.2.2.1. An object can have shared and a private portion
12.2.2.1.1. Shared via API
12.3. Other Software Development Concepts
12.3.1. Data Modelling
12.3.1.1. Pointers must point to the right place
12.3.2. Data Structures
12.3.3. Cohesion and Coupling
12.3.3.1. Cohesion
12.3.3.1.1. How many functionalities can a module carry out? Less is better
12.3.3.2. Coupling
12.3.3.2.1. How many other modules a module need to carry out its tasks?