Software Development Security - Domain 4 Flashcards
Q
A
Software Development - Waterfall Method
- Traditional Model. 2. Completion of one task leads to the start of another. 3. Long term projects (inflexible).
Software Development - Prototyping method
- Addresses time issues with Waterfall. 2. Produces basic prototypes that evolve each round. 3. 1970’s
Software Development - Prototyping method - 4 phases
- Initial concept. 2. Design and implement initial prototype. 3. Refine prototype until acceptable. 4. Complete and release final version. 5. 1980’s
Software Development - Spiral Method
- Combo of Waterfall and Prototyping. 2. Development of initial version is based on prototyping. 3. Development of each version is similar to waterfall. 4. Risk analysis after each step.
Software Development - Clean room method
- Engineered development process. 2. Focus on defect prevention instead of defect removal. 3. Increased design time reduces requirements for testing. 4. Results in substantial savings over the long term.
Software Development - Extreme programming method
- Function specific programming instead of application. 2. Executed by small teams. 3. Dynamic changing requirements.
Software Development Models - Generic steps
- Project initiation. 2. Functional design analysis and planning. 3. System design specifications. 4. Software development. 5. Installation/Test/Implementation. 6. Operation/maintenance. 7. Disposal.
Software Development - Project Initiation (Step 1)
- Conceptual definition of project is decided upon. 2. Identify security requirements. 3. Perform an initial risk analysis-analyze threats and countermeasures and estimate costs and benefits per countermeasure. 4. Identify security framework. 5. Determine SLA.
Software Development - Function Design (Step 2)
- Define security requirements. 2. Propose security checkpoint plan. 3. Develop contingency plans. 4. Preliminary security test plans. 5. Formal functional baseline includes security requirements.
Software Development - System Design (Step 3)
- Define security specifications. 2. Update test plans involving security. 3. Security specifications. 4. System design checklist. 5. Formal methods developed.
Software Development - Software Development (Step 4)
- Write programming code to meet specifications. 2. Implement security within code. 3. Perform unit tests.
Software Development - Testing and Installation (Step 6)
- Test system components. 2. User acceptance testing, data checking, and resiliency testing. 3. Install system. 4. Create manuals. 5. Perform acceptance test - certification and accreditation. 6. Accept system. 7. Garbage collection.
Software Development - Testing Types (Step 7)
- Unit testing - individual component is in a controlled environment where programmers validate data structure, logic, and boundary conditions. 2. Unit testing - verifying that components work together as outlined in design specifications. 3. Acceptance testing - ensuring that the code meets customer requirements. 4. Regression testing - after a change to a system takes place, restesting to ensure functionality, performance and protection.
Software Development - Testing techniques
- Black box testing - tester has no knowledge of system. 2. White box - tester has full knowledge of system. 3. Gray-box - tester has partial knowledge of system.
Software Development - Operation
- Maintain system through service level agreement 2. After changes re-certify 3. Audit and test security components periodically.
Software Development - Disposal
- Properly dispose of system 2. Repeat full cycle with a new project initiation 3. data moved to another system or discarded.
Software Development - Verification
- Determine if the product accurately represents the developers description and specifications. 2. Follows structure and logic o fo product.
Software Development - Validation
- Determine the degree to which the model represents a real world use. 2. Does the product actually solve a problem and or meet a demand?
Software Development - Change Control
- Without proper change control, a project can take longer that appropriate to complete. 2. Applications should be centrally managed. 3. Security controls must always be protected. 4. Programmer changes must be made through controlled libraries. 5. Changes should be made to source code and not production code.
Software Development - Change Control Procedure
- Request for change is formally made to CCB. 2. Analyze request - a. develop the implementation strategy b. calculate the cost of this implementation c. review any security implications. 3. Record change request. 4. Submit change request for approval. 5. Develop change. 6. Re-code segments of the product and modify functionality. 7. Link these changes in the code to formal change control request. 8. Submit software for testing and quality approval. 9. repeat until quality is adequate. 10. Make version changes. 11. Report changes to management. 12. Establish a baseline setting.
Software Development - Change Control Issues
- Changes must be submitted, approved, tested, and recorded. 2. Logic of change is separate from the process of change control.
Computer aided software engineering (CASE)
- General term for a wide variety of tools to help programmers, project managers, and analysts during a project. 2. Automation of repetitive tasks. 3. Debuggers, code analyzers, version control tools. 4. Development is quicker and more accurate with computer aided tools. 5. Allows for rapid prototyping.
Capabilities Maturity Model (CMMI)
- Developed by Software Engineering Institute at Carnegie-Mellon Uni in Pitts. 2. Assumes that the quality of the software development process directly impacts the quality of the software product. 3. Five maturity levels for software development.
CMMI Levels
- Initiating 2. Repeatable 3. Defined 4. Managed 5. Optimization
Object Oriented Programming (OOP)
- Increases speed in software development because objects can be reused. 2. Saves money and time.3. Closely maps to real activities. 4. Self contained. 5. Highly modular.
OOP Terms
- Inheritance 2. Abstraction 3. Encapsulation 4. Polymorphism 5. Polyinstantiation
OOP Terminology
- Classes - defines attributes and characteristics of the possible objects within them (objects are members of classes). 2. Objects - software entities that are grouped into classes (objects inherit attributes from class type).
OOP Objects
- re-useable module of code. 2. Each re-use of the object creates an instance. 3. Modularity approach provides more efficiency and structure.
OOP Behavior
- Commands performed by object are a method. 2. Objects communicate with each other through messages.
Abstraction
- Looking at the “big picture” versus focusing on all the small details of the picture. 2. Suppressing unnecessary detail so that overall goal of an object can be utilized.
Abstraction Example - Objects
- Characteristics of objects are encapsulated - only accessible through messaging. 2. Viewed as a black box - internal workings are not apparent to the system.
Polymorphism
Two objects are sent the same message but react differently-this is possible because objects can belong to different classes, meaning they will exhibit different behaviors.
Polyinstantiation
The creation of another version of an object using different values for its variables to ensure that lower level subjects do not access data at a higher classification.
Module Interaction - Cohesive
- Object is highly cohesive if it can perform a task with little or no help from others. 2. Highly cohesive objects are not as dependent upon other objects as low cohesive objects. 3. Higher cohesive objects are better.
Module Interaction - Coupling
- Measurement of interaction between objects. 2. Lower coupling means less interaction. 3. Lower coupling provides better software design because objects are more independent. 3. Lower coupling is easier to troubleshoot and update.
Data Base Types
- Relational - presents data in tables with columns and rows (attributes and tuples). 2. Hierarchical - logical tree structure (branches and leaves-data fields). Highest node is root; parents can have children. 3. Distributed - data is stored in bases in different places and a re logically connected.
dBase Terminology - Attribute
Column in a relational dbase.
dBase Terminology - Tuple
A row representing a relationship among values.
dBase Terminology - Cell
The intersection of the row and column in a relational dbase.
dBase Terminology - Element
Each data value in a row under a column.