Domain 8 - Software Development Security Flashcards
1
Q
What does the Stride threat model stand for?
A
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Escalation of Privilege
2
Q
What is the mitigation for Spoofing?
A
Authentication
3
Q
What is the mitigation for Tampering?
A
Integrity Verification (Message Digest etc)
4
Q
What is the mitigation for Repudiation?
A
Non-Repudiation (Digital Signatures, Keys etc)
5
Q
What is the mitigation for Information Disclosure?
A
Confidentiality through encryption
6
Q
What is the mitigation for Denial of Service?
A
High Availability/Redundancy/Fault Tolerance
7
Q
What is the mitigation for Escalation of Privilege?
A
Authorization
8
Q
What does the DREAD bug tracking classification stand for?
A
D - Damage Potential R - Reproducibility E - Exploitability A - Affected User Base D - Discoverability
9
Q
What is the difference between Verification and Validation checks?
A
Verification is the assessment of whether a system was built to specification. Validation is the acceptance of the system.
10
Q
What is the nature of Object-Oriented Programming?
A
Object Orientated is modular and reusable through using objects, classes, methods and functions.
11
Q
What are Classes and Objects?
A
Class is a concept (ie people) and an Object brings that concept to life (ie user accounts).
12
Q
What is an example of a Primary Key in a database?
A
ID=1
13
Q
What is Entity Integrity in Databases?
A
Primary key (ID=1) cannot be NULL
14
Q
What is Normalization in Databases?
A
Each attribute in a database must describe ONLY the primary key. This helps to prevent duplicate information.
15
Q
What are Attributes in Databases?
A
They are the entries in a table which reference the Primary key (for example name, address etc of ID=1)
16
Q
What is the Tulpes in a Database?
A
Tuples is the data in rows, usually called records (this is important for the exam)
17
Q
What is a Foreign Key in a Database?
A
Is when the Primary Key from one table appears in a secondary database (Customer ID and Order ID etc).
18
Q
What is the Cardinality in a Database?
A
How many times a Primary key is referenced in another databases row relation.
19
Q
What is Degree in a Database?
A
How many times a Primary key is referenced in another databases column relation.
20
Q
What is the threat of Aggregation and Inference in Databases?
A
When you can draw a connection between two datasets (somebody was sick, didn’t drink and went to the doctor = pregnant)
21
Q
What is Polyinstantiation for Databases?
A
Lying (instead of marking the destination of a ship as top secret, it should be marked as delivering food in Africa so that it doesn’t draw attention)
22
Q
What does the Atomicity test for Databases?
A
Transactions are either fully committed or rolled back (halfway through paying and the power cuts out)
23
Q
What does the Durability test for Databases mean?
A
Once a change has been committed, the transaction can’t be rolled back
24
Q
What does the Isolation test for Databases mean?
A
Transactions are invisible until committed
25
What does the Consistency test for Databases mean?
Database rules are enforced
26
What does ACID stand for in relation to Database testing?
A - Atomicity
C - Consistency
I - Isolation
D - Durability
27
A process that provides clear and logical steps that should be followed to ensure that the system which emerges at the end of the development process provides the intended functionality, with an acceptable level of security.
System Development Life Cycle
28
A collection of computer instructions written using some readable (human readable) computer language.
source code
29
These deliver instructions directly to the processor using binary instructions without an interpreter or compiler. Characteristics include: time consuming, prone to errors, short in length, and rudimentary progress.
machine languages
30
This category emerged in the 1990's. The goal is to create software that can solve problems on its own rather than requiring a programmer to create code to deal with a problem. AI and knowledge-based processing fall within this category.
natural languages
31
This category is one step above machine languages and uses symbols or mnemonics to represent sections complicated binary code. This uses a simplified code and an assembler to convert code to machine language; requires extensive architecture knowledge; code is hardware specific; and it is difficult to create/write.
assembly languages
32
Developed in the 1960's it uses "if-then-else" statements. Characteristics include: independent processor; human-like syntax (easier to use); does not require a compiler or interpreter to convert instructions into machine code.
high-level languages
33
A fourth generation of languages that focuses on abstract algorithms that hide some of the complexity from the programmer. This frees the programmer to focus on the real-world problems to be fixed in the software (to solve) rather than focusing on behind the scenes.
very high-level languages
34
A code that has already been translated to binary language; it is difficult to detect malicious code in this type of code.
compiler (compiled)
35
This type of code uses a piece of software that allows the end user to write human-like, readable code; a program can then be executed directly by this component, which make it somewhat easier to read (see) malicious code.
Interpreters (interpreted)
36
A type of programming in which objects are organized in a hierarchy in classes with characteristics called attributes attached to each. This programming type emphasizes the employment of objects and methods rather than types of transformations as in other software approaches.
Object-Orientated Programming (OOP)
37
The software program allows for objects to be created on demand, through request from objects that need a new function to be performed. Requests are instantiated (built in) with the necessary code. The objects can be written in any language as long as the objects can communicate with each other.
created classes/objection (OOP)
38
Objects are able to communicate with each other regardless of the language type, to make requests. This is what makes the communication possible.
application program interface (API) (OOP)
39
Functionalities or procedures of objects organized into classes; defines how an object behaves or reacts to a message.
methods (OOP)
40
This allows for methods to be passed from a class to a subclass.
inheritance (OOP)
41
The object contains attribute values (messages to be sent to another object's API).
encapsulate (OOP)
42
When different objects may communicate or react differently to the same message (the code that defines how an object will react with respect to the message is called the method).
behaviors (OOP object behaviors)
43
Encapsulation is another name of this technique. It is the process of hiding or keeping private some parts of an object's internal data operations.
data binding (OOP)
44
Is the ability to suppress unnecessary details.
abstraction (OOP)
45
Uses data types with define ranges; programmers must identify all data objects and their relationships using this technique. The object is then generalized into an object class, defined as part of a log sequence (method) used to manipulate an object.
data modeling (OOP)
46
Examples of this category include C++, Simula 67, and smalltalk.
languages (OOP)
47
Modularity in design through autonomous objects; definition of internal components without impacting other parts of the system; reusable components; and more readily maps to business needs.
Advantages of OOP
48
The ability of different objects with a common name to react to the same message or input with different output.
polymorphism
49
A process used to prevent data inference violations. It does this by enabling a relation to contain multiple tuples with the same primary keys with each instance distinguished by a security level. It prevents low-level database users from inferring the existence of higher level data.
polyinstantiation
50
In software development, this technique protects objects by preventing direct access to data that is in the object; makes it hard to apply the appropriate security policies to an object because it is hard to determine.
encapsulation
51
A term used to describe how many different tasks a module can carry out; if a module is limited (small number) or has a single function it is said to have high this quality.
cohesion
52
Changes can be made to the model without affecting the other modules; it makes reuse of the object easier.
high cohesion
53
Limiting the scope of a module's operations.
How the highest cohesion achieved.
54
Refers to how much interaction one module requires from another module to do its job. If this is low or loose, it indicates a module does not need much help from other modules to do its job and a high value means it needs more help.
coupling
55
High cohesion and low coupling.
Best programming situation.
56
The logical relationship between elements of data. It describes the extent to which elements, methods of access, and processing alternatives are associated and the organization of data elements.
data structure
57
Systems whose components must be able to both locate each other and communicate on a network. When an application operates in a client/server framework the solution is performing this type of computing.
distributed object-orientated systems
58
Common Object Request Broker Architecture
CORBA
59
An open object-orientated standard developed by the Object Management Group (OMG).
Common Object Request Broker Architecture (CORBA)
60
CORBA is responsible for enforcing the security in four types of policies:
1. Access control; 2. Data protection; 3. Non-repudiation; and 4. Auditing
61
It accepts requests for service from the client application, directs the request to the server, then relays the response back to the client application. It can be used for objects written in different languages.
CORBA
62
A model for communication between processes on the same computer.
Component Object Model (COM)
63
A model used for communication between processes in different parts of the network.
Distributed Component Object Model (DCOM)
64
This works as middleware between remote processes; also referred to as interprocess communication (IPC).
The function of DCOM.
65
Services provided by DCOM.
1. Data connectivity; 2. Message services; 3. Distributed transaction services. These functions are integrated into one technology that uses the same interface as COM.
66
A method for sharing object on a local computer that uses COM as its foundation. It is described as the predecessor of COM. It allows objects to be embedded into spreadsheets and graphics.
Object Linking and Embedding (OLE)
67
Placement of data into a foreign program or document.
embedding
68
Relationship between one program and another.
linking
69
A distributed component mode; its framework is used to develop software that provides APIs for networking services and uses interprocess communication process that is based on CORBA.
Java Platform Enterprise Edition (J2EE)
70
To provide a standard method of providing a back-end code that carries out business logic for enterprise applications.
J2EE goals
71
An approach that provides web-based communication functionality without requiring redundant code to be written per application. It uses standard interfaces and components called service brokers to facility communication among web-based applications.
Service Orientated Architecture (SOA)
72
Instructions passed across a network and executed on a remote system. As a security concern, it can be remotely executed without the user's knowledge.
mobile code
73
A small component created using Java that runs in a web browser. It is platform independent and creates intermediate code called "byte code." As a security issue, these have the potential to download loose code.
Java applet
74
It resides on the destination machine and converts byte code to machine code. It executes Java applets in a sandbox called the Java Security Mode (JSM). This helps to mitigate malicious code but cannot completely stop it.
JVM
75
A Microsoft technology that uses object-orientated programming (OOP) and is based on COM and DCOM. It uses "authenticode" technology to digitally sign controls, which can become malicious if the user has Admin rights.
Active X
76
Most suspicious: Java applets or Active X?
Active X
77
The Five Phases of software development.
1. Initiate. 2. Acquire and develop. 3. Implement. 4. Operate and maintain. 5. Dispose
78
A predictable framework of procedures designed to identify all requirements with regard to functionality, cost, reliability, and delivery schedule and ensure that all these requirements are met in the final software solution.
Software Development Life Cycle
79
Recognize the need for a change. Initiate the change. Decide if it is something that needs to be purchased or internally developed. Create a preliminary risk assessment to conducer how to maintain the security of the CIA triad tenets.
Project Initiation (Phase 1 of the System Development Life Cycle)
80
The organization works to determine and consider questions to help decide whether to purchase (acquire) or develop the new software.
Acquire and Development (Phase 2 of the System Development Life Cycle)
81
This is the "acquire and develop" stage and the questions to consider include: What does the new system need to perform? What CIA risks does the solution pose? What levels of protection are needed to satisfy legal/regulatory requirements? How do third-parties address these concerns? How will security controls for the new solution affect other parts of the organization? And, what metrics will be used to measure success of the security?
Questions to ask in Phase 2 (Acquire and Develop phase of the System Development Life Cycle)
82
Complete certification and accreditation before introducing the solution into the live environment.
Implement (Phase 3 of the System Development Life Cycle)
83
The technical evaluation of a system. It is the process of evaluating software for its security effectiveness with regards to the customer's needs.
certification
84
The formal acceptance of the adequacy of a system's overall security by the management. This has two forms: provisional and full.
accreditation
85
A baseline performance is measured after the system is installed. The baselines are monitored for changes as that may need to be quickly addressed. The formal change management process is used to ensure the changes are approved and documented, then the baselines are re-monitored for changes after the implementation. Last, a vulnerability and penetration test is completed to review security.
Operate and maintain (Phase 4 of the System Development Life Cycle)
86
The IT process which ensures that all changes are both approved and documented.
Change Management Process
87
When the solution reaches the end of its life cycle questions are considered prior to ending the solution: Will security holes be left after removing the solution? How can the solution be removed without disrupting other operations that were part of, or depend on, or interact with the solution? What legal/regulatory issues have to be considered before removing the solution?
Disposal (Phase 5 of the System Development Life Cycle)
88
1. Plan and initiate he project; 2. Gather requirements; 3. Design; 4. Develop; 5. Test and validate; 6. Release and maintains; 7. Certify and accredit; and 8. Change management and configuration management and or replacement.
Steps in the Software Development
89
The organization formally plans the project. Security of the application is considered. The owner assigns value. Legal/regulatory requirements are documented. Application controls are used to protect input/output data. The types of network needs are determined. Analyze all data source and the effects of the use of the application on the organization's operations.
Plan and initiate the project (Step 1 of the SDLC)
90
Functionality and security requirements are identified. Identify vulnerabilities and threats. Consider the intended purpose of the software. Consider the sensitivity of the data that will be generated. Assign a privacy impact rating to help guid all measures used to protect the data.
Gather requirements (Step 2 of the SDLC)
91
This involves writing of the code with an emphasis on strict coding security.
Develop (Step 3 of the SDLC)
92
Runs several types of testing, and validating. Looks for functional errors and security issues. Tests are "attacked" to show the software includes resilience to buffer overflows and DoS attacks, this is done in unit testing. The testing goals are: 1. verification and 2. validation.
Test and validate (Step 5 of the SDLC)
93
Test determines whether the original purpose of the software has been achieved.
Validation testing
94
Test determines if the original design specifications have been met.
Verification testing
95
This type of testing is done by the development staff. It tests that the data is part of the specifications previously outlined. This type of testing checks for out-of-range values and out-of-bound conditions. Correct test output results should be developed and known before hand. Types of this test include: integration testing, acceptance testing, and regression testing.
Unit testing
96
Assess the way in which the modules work together and determines whether functional and security specifications have been met.
Integration testing
97
Testing to ensure that the customer's (either internal or external) is satisfied with the functionality of the software.
acceptance testing
98
Takes place after changes are made to the code to ensure the changes have neither reduced functionality or security.
regression testing
99
Implementation of the software into the live environment. Continued monitoring of its operation; this is where problems may appear, such as zero-day vulnerabilities, because no one knows it is there.
Release and maintain (Step 6 of the SDLC)
100
This is not a two-step process. One can be done without the other. In the certification process the software will be evaluated for its security effectiveness in regards to the customer's needs. Accreditation list he formal acceptance of the adequacy of the a system's overall security by management. The process can include provisional accreditation or full accreditation.
Certification and accreditation (Step 7 of the SDLC)
101
A specific time frame until changes that are listed, have been made, prior to granting full accreditation.
provisional accreditation
102
This is granted once everything has been completed, analyzed, and approved by a certifying body.
full accreditation
103
If changes need to be made to the software code, the changes are done first through a formal change and configuration management process.
Change management and Configuration Management/replacement (Step 8 of the SDLC)
104
A software development method, not discredited, but remains a template for how NOT to manage a development process. Software is developed as quickly as possible and then released. There is no formal mechanism to provide feedback during the process. It quickly gets the product to market with problems that will later need to be patched or have service packs applied.
Build and Fix
105
A software development model that breaks the software development process into distinct phases. While somewhat of a right approach, it sees the process as a sequential series of steps that are followed without going back to the earlier steps. This approach is called the incremental development and it never returns to the earlier steps.
Waterfall Model
106
Each phase of the software development is its own milestone in the project management process. There is no backward iteration. Problems are dealt with after the project is complete. Product verification/validation are done in this model.
Modified Waterfall Model
107
A software development model in which verification and validation are performed at each step. The result is a higher likelihood of success.
V-Shaped Model
108
A software development method that uses a sample code to explore a specific approach to solving a problem before investing extensive time and money in the approach. This method saves time and money by building and designing before a full model is built.
Prototyping
109
Three testing types: Integration, Acceptance, and Regression.
Unit Testing
110
Software Development Acquisition Stages
Monitor, Plan, Contract, and Maintain
111
Phases of System Development Life Cycle
Initiate, Acquire/Develop, Implement, Operate/Maintain, and Dispose
112
Steps in the Software Development Life Cycle
Plain and Initiate, Gather requirements, Design, Develop, Test and validate, Release and Maintain, Certify and Accredit, Change and configuration management or replacement
113
System Development Life Cycle (SDLC) versus Software Development Life Cycle (processes)
The Software Development Life Cycle processes and the System Development Life Cycle processes are both parts of the overall System Life Cycle.
114
An API used with software the provides encryption.
Cryptographic Application Programming Interface (CASE)
115
An encryption API that is used with developing and maintaining software. It provides the following functions: analysis of business functions, system design, code storage, uses compilers, provides translation, and software testing.
Computer Aided Software Engineering (CASE)
116
Types of validation controls.
Pre-validation, Parameter validation, and Post-validation.
117
This input control is implemented on the client side and occurs before being submitted to an application.
Pre-validation control
118
This input control has validated values that are entered into an application. The values must be within the server's set limits.
Parameter validation control
119
This input control validates an application's output is restricted to a pre-defined definition.
Post-Validation control
120
Confidence in the security mechanism(s) being provided in the software.
Assurance
121
Two parts of the Life Cycle Assurance process.
Product Development and Product Maintenance
122
Trusted distribution, design specification, unit and integration testing, configuration management, and clipping level configurations.
Types of Life Cycle Assurance Parameters
123
Software Assurance (Acquisition) Phases (SwA)
Planning phase, Contracting phase, Monitoring and Accepting phase, and Follow-on Phase.
124
SwA Phase: The company sets out the objectives and the goals are described; meeting with the different teams; and overall proper security assessment (such as in an acquisition or merger) is addressed.
Planning Phase
125
SwA Phase includes: Creating a request for proposal (RFP); accepting vendor bids; and the company choses a vendor's bid. The vendor reviews the contract to ensure it meets all the required conditions. A Code Escrow should also be put in place during this phase.
Contracting Phase
126
SwA Phase includes: Deployment of software; working with vendor to ensure all requirements are being met; focus on training and understanding how the deployed program is functioning.
Monitoring and Acceptance Phase
127
SwA Phase includes: Organization ensures the product is kept up-to-date and maintained by the third-party or vendor. It could also include decommissioning the program if it has reached the end of its life cycle.
Follow-On Phase
128
1. Determine the state of the organization's current software development processes.
2. Use the software development process to gain support from within the organization for a software processes improvement program.
3. Develop an action plan for a continuous software process improvement plan.
Software processes assessment
129
This interface language is used for web technologies and it also uses tags.
extensible markup language (XML)
130
This is has an API that allows Java to communicate with a database.
Java Database Connectivity (JDBC)
131
This links data between different databases.
object linking and embedding database (OLE DB)
132
This uses ActiveX data objects and is an API that allows ActiveX programs to query databases.
ActiveX Data Objects (ADO)
133
A type of API that provides encryption.
Cryptographic API (CAPI)
134
This is a software tool that is used to develop and maintain application software. It can be used to review business functions, the design of the system, store code, compile, translate, and test software during the development process.
Computer-aided software engineering (CASE)
135
Two parts of the System Life Cycle (SLC)
Operations and Maintenance Support (post installation); and Revisions and System Replacement
136
In this phase of software acquisitions the product is deployed, the complier completes the contract, and the buyer of the product formally accepts the final product.
Monitoring Phase
137
In this phase of software acquisitions the software requirements are documented, an acquisition strategy is created, and the evaluation criteria is developed.
Planning Phase
138
In this phase of software acquisitions a request for proposal (RFP) is issued, the proposal is evaluated, and the final contract is negotiated and completed between the seller and the buyer.
Contracting Phase
139
In this phase of software acquisitions the software is maintained and later considers the decommission of the software when it is no longer needed or updatable.
Maintaining Phase
140
This ensures that the attributes in a database table depend only on the primary key.
Normalization
141
This prevents repetitive information from appearing in a database.
Normalization
142
This makes it easier to manage and maintain consistency in a database.
Normalization
143
In this process the software is debugged, checked for valid parameters, and allows for corrections to be made where needed.
Unit Testing
144
This allows for direct communication between two applications using the interprocess communications (IPC). It is based on a client/server model and allows the exchange of data between the client and the server.
Dynamic Data Exchange (DDE)
145
This type of attack occurs a little at a time, over time, and is repeated often, most likely by an insider. It is also similar to Data Diddling.
Salami Attack
146
In the SDLC, this includes identification of threats and vulnerabilities; requires getting management approval; performs a risk analysis and evaluates the environment in which the software will run data processing.
Project initiation and Planning
147
Certification and Accreditation occur in this phase of the SDLC.
Testing and Evaluation Control
148
In this phase of the SDLC the formal functional baselines and security tasks are defined in the design of the software.
Functional Requirements and Definitions
149
A communication paths that is not controlled by any security mechanism and gains access to information via an unauthorized means to violate the security policy.
Covert Channel
150
TSCEC B3 addresses this type of Covert Channel.
Covert Timing Channel
151
TSCEC B2 address this type of Cover Channel.
Covert Storage Chanel
152
This is a type of ICMP back door tunneling attack that is considered a covet channel attack.
Loki Attack
153
Configuration Management versus Change Management
Change Management falls under Configuration Management.
154
Configuration: Identification, Control, Status Accounting, and Audits.
Configuration Management (steps)
155
Configuration Management
1. Make formal request
2. Analyze request
3. Record the change request
4. Submit the change request for approval
5. Make changes
6. Submits the results to management for review
156
A Microsoft high-level interface for many types of data.
ActiveX Data Objects (ADP)
157
Maturing model focused on quality management processes and has five maturity levels that contain several key practices within each maturity level.
Capability Maturity Model for Software (CCM or SW-CMM)
158
A set of standards that addresses the need for interoperability between hardware and software products.
Common Object Request Broker Architecture (CORBA)
159
A program written with functions and intent to copy and disperse itself without the knowledge and cooperation of the owner or user of the computer.
Computer Virus
160
Monitoring and management changes to a program or documentation.
Configuration Management (CM)
161
An information flow that is not controlled by a security control.
Covert Channel
162
The conversion of electronic data into an other form, called cipher text, which cannot be easily understood by anyone except authorized parties.
Encryption
163
The practice of examining large database in order to generate new information.
Data Mining
164
A suite of application programs that typically manages large, structured sets of persistent data.
Database Management System (DBMS)
165
Describes the relationship between the data elements and provides a framework for organizing the data.
Database Model
166
An approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collaborate.
DevOps
167
A record of the events occurring within an organization's systems and networks.
Log
168
A management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize the design, manufacturing, and supportability processes.
Integrated Product and Process Development (IPPD)
169
Development models that allow for successive refinements of requirements, design, and coding.
Iterative Models
170
A mathematical, statistical, and visualization method of identifying valid and useful patterns in the data.
Knowledge Discovery in Databases (KDD)
171
Information about the data.
Metadata
172
A form of rapid prototyping that requires strict time limits on each phase and relies on tools that enable quick development.
Rapid Application Development (RAD)
173
The level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that it functions in the intended manner.
Software Assurance (SwA)
174
Allows the operating system to provide well-defined and structured access to processes that need to use resources according to a controlled and tightly managed schedule.
Time Multiplexing
175
Takes advantage of the dependency on the timing of events that takes place in multitasking operating system.
Time of Check/Time of Use (TOC/TOU) Attacks
176
The collection of all the hardware, software, and firmware within a computer system that contains all elements of the system responsible for supporting the security policy and the isolation of objects.
Trusted Computing Base (TCB)
177
A development model in which each phase contains a list of activities that must be performed and documented before the next phase begins.
Waterfall Development Model
178
Initiating, Diagnosing, Establishing, Acting, Learning
IDEAL model
179
Conception, Initiation, Analysis, Design, Construction, Testing, Deployment
Agile model
180
Change Management steps
Request control, change control, release control
181
Configuration Management steps
Configuration identification, configuration status accounting, configuration audit
182
full commitment of transaction
atomicity
183
enforces integrity rules in the database
consistency
184
commit must be received 100% before transaction can be viewed
isolation
185
transaction can't be rolled back after committed
durability
186
The process of brining the database into compliance or minimizing redundancy.
normalization
187
The purpose of this model is to define the organization's maturity level in the software development process and project management cycle.
Software Capability Mature Model (SW-CMM)
188
SW-CMM steps
Initial, Repeatable, Defined, Managed, Optimized
189
Describes the nature of the Ad hoc process of the SW-CMM rating.
Initial
190
Describes the managed stage and improvement in process in the SW-CMM rating.
Repeatable
191
Describes the well-defined process and quality management of the SW-CMM rating.
Defined
192
Describes the continuous improvement processes and "kaizen" of the SW-CMM rating.
Optimizing
193
In the software development life cycle these two processes should always fall under separation of duties to prevent a conflict of interest.
testing and development
