Software Development Security - Domain 4 Flashcards
1
Q
Q
A
A
2
Q
Software Development - Waterfall Method
A
- Traditional Model. 2. Completion of one task leads to the start of another. 3. Long term projects (inflexible).
3
Q
Software Development - Prototyping method
A
- Addresses time issues with Waterfall. 2. Produces basic prototypes that evolve each round. 3. 1970’s
4
Q
Software Development - Prototyping method - 4 phases
A
- Initial concept. 2. Design and implement initial prototype. 3. Refine prototype until acceptable. 4. Complete and release final version. 5. 1980’s
5
Q
Software Development - Spiral Method
A
- 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.
6
Q
Software Development - Clean room method
A
- 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.
7
Q
Software Development - Extreme programming method
A
- Function specific programming instead of application. 2. Executed by small teams. 3. Dynamic changing requirements.
8
Q
Software Development Models - Generic steps
A
- Project initiation. 2. Functional design analysis and planning. 3. System design specifications. 4. Software development. 5. Installation/Test/Implementation. 6. Operation/maintenance. 7. Disposal.
9
Q
Software Development - Project Initiation (Step 1)
A
- 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.
10
Q
Software Development - Function Design (Step 2)
A
- Define security requirements. 2. Propose security checkpoint plan. 3. Develop contingency plans. 4. Preliminary security test plans. 5. Formal functional baseline includes security requirements.
11
Q
Software Development - System Design (Step 3)
A
- Define security specifications. 2. Update test plans involving security. 3. Security specifications. 4. System design checklist. 5. Formal methods developed.
12
Q
Software Development - Software Development (Step 4)
A
- Write programming code to meet specifications. 2. Implement security within code. 3. Perform unit tests.
13
Q
Software Development - Testing and Installation (Step 6)
A
- 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.
14
Q
Software Development - Testing Types (Step 7)
A
- 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.
15
Q
Software Development - Testing techniques
A
- 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.
16
Q
Software Development - Operation
A
- Maintain system through service level agreement 2. After changes re-certify 3. Audit and test security components periodically.
17
Q
Software Development - Disposal
A
- Properly dispose of system 2. Repeat full cycle with a new project initiation 3. data moved to another system or discarded.
18
Q
Software Development - Verification
A
- Determine if the product accurately represents the developers description and specifications. 2. Follows structure and logic o fo product.
19
Q
Software Development - Validation
A
- 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?
20
Q
Software Development - Change Control
A
- 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.
21
Q
Software Development - Change Control Procedure
A
- 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.
22
Q
Software Development - Change Control Issues
A
- Changes must be submitted, approved, tested, and recorded. 2. Logic of change is separate from the process of change control.
23
Q
Computer aided software engineering (CASE)
A
- 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.
24
Q
Capabilities Maturity Model (CMMI)
A
- 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.
25
CMMI Levels
1. Initiating 2. Repeatable 3. Defined 4. Managed 5. Optimization
26
Object Oriented Programming (OOP)
1. 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.
27
OOP Terms
1. Inheritance 2. Abstraction 3. Encapsulation 4. Polymorphism 5. Polyinstantiation
28
OOP Terminology
1. 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).
29
OOP Objects
1. re-useable module of code. 2. Each re-use of the object creates an instance. 3. Modularity approach provides more efficiency and structure.
30
OOP Behavior
1. Commands performed by object are a method. 2. Objects communicate with each other through messages.
31
Abstraction
1. 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.
32
Abstraction Example - Objects
1. Characteristics of objects are encapsulated - only accessible through messaging. 2. Viewed as a black box - internal workings are not apparent to the system.
33
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.
34
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.
35
Module Interaction - Cohesive
1. 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.
36
Module Interaction - Coupling
1. 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.
37
Data Base Types
1. 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.
38
dBase Terminology - Attribute
Column in a relational dbase.
39
dBase Terminology - Tuple
A row representing a relationship among values.
40
dBase Terminology - Cell
The intersection of the row and column in a relational dbase.
41
dBase Terminology - Element
Each data value in a row under a column.
42
dBase Terminology - File
Table - collection of records of the same type.
43
dBase Terminology - Base Relation
A table stored in a database.
44
dBase Terminology - View
A virtual relation defined by database to control subjects viewing certain data (a.k.a. role-based access control).
45
dBase Terminology - Primary Key
A field that links all the data within a record to a corresponding value.
46
dBase Terminology - Foreign Key
An attribute of one table that is the primary key of another table.
47
dBase Terminology - Schema
Holds data that describes a dbase.
48
dBase Terminology - Meta Data
Data about data-data to describe a base and the data within.
49
Data Dictionary
1. Central repository of meta-data, which is critical information about the whole database. 2. Cross reference between the groups of data elements and how they interact with each other (relationships). 3. A central cllection of data element definitions, schema objects, and reference keys. 4. Allows for central management of dbase. 5. Central catalog of data.
50
Open dBase Connectivity (ODBC)
1. Allows applications to communicate with different types of bases. 2. Interface between the application and the different base drivers.
51
Data Warehousing
1. Combines data from multiple bases into a larger base with the purpose of a fuller extent of information retrieval and data analysis. 2. Extracting operational data and making it into informational data. 3. Not just mirroring data. 4. Redundancies and inconsistencies are removed.
52
Data Mart
1. Smaller and more focused on a particular subject when compared to a data warehouse. 2. A Data Warehouse combines data across an enterprise. 3. A data mart can access data for specific groups.
53
Data Mining
1. The process of analyzing a base using tools that look for trends or anomalies without having the knowledge of the meaning of the data. 2. Creates meta-data which is more useful to the user. 3. Identifies patterns and relationships between data sets. 4. Can be used to test for inference vulnerabilities.
54
Software Security Downfalls
1. Most attacks take advantage of a weakness or vulnerability in some type of software. 2. Security controls are deployed to prevent attackers from exploiting those weaknesses. 3. Software is a critical component of all business transactions. 4. Software is changing than software security technology.
55
Software Security Challenges
1. It was not as crucial to implement security during the development stages. 2. Many programmers do not practice these procedures. 3. A majority of security professionals themselves are not software developers. 4. Software vendors rush products to market with their eyes set on functionality, not security.
56
Approches to SW Security
1. Firewalls, routers, ACL’s, IDSs, bastion hosts -vs- 2. Design and develop software with security in mind - ISO 27034.
57
Software Security - Seperation of Duties
1. Programmers shouldn't be the only ones testing their software- a. operations should not have access to source or object code in production b. programmers should not be interacting with software in production. 2. Once software is completed, it should go to the library- a. software released to production should come in a library, not directly from programmers b. proper testing is managements responsibility.
58
dBase ACID Test - A
Atomicity - either all changes take effect or none do.
59
dBase ACID Test - C
Consistency - A transaction is allowed only if it follows owner - or system - defined integrity constraints.
60
dBase ACID Test - I
Isolation - the results of the transaction are not visible until the transaction is complete.
61
dBase ACID Test - D
Durability - the results of a completed transaction are permanent.
62
dBase Security Mechanisms and Issues
1. Concurrency problems. 2. Checkpoints. 3. Trusted front end. 4. Aggregation. 5. Inference. 6. views.
63
dBase Security Mechanisms Add-on Example - Trusted front-end
1. Adds multilevel security to a dbase. 2. Another control between subjects and objects. 3. Used to retrofit security to a dbase.
64
dbase Security Attacks - Aggregation
1. Act of combining information from separate sources. 2. this combination forms new information, to which the subject does not have authorized access. 3. The combined information has a sensitivity that is greater than the individual parts.
65
dbase Security Attacks - Inference
1. Inference is the ability to derive additional information from learned facts about a particular system. 2. Countermeasures: cell suppression, pertaining, insertion of noise data, polyinstantiation.
66
Controlling dBase access - Content dependent
1. Controlling access based on contents of the object. 2. Query results depend upon the values within tables.
67
Controlling dBase access - Context dependent
1. Access decision based on the context of the request. 2. Mechanism required to keep track of who accessed and in what sequence.
68
dBase Integrity - Entity
1. No primary key attribute can have a null value. 2. Primary key value must be unique.
69
dBase Integrity - Referential
1. When there is a relationship between two entities, those two entities need to actually exist. 2. No record can contain a reference to a key of a non-existing record.
70
Distributed Computing
Data processing takes place on different systems: 1. Common object request brokers (CORBA, ORB). 2. Distributed communication standard (COM-Component Object Model, dCOM-distributed COM). 3. Enterprise Java Bean (EJB). 3. Simple Object Access Protocol (SOAP).
71
DCOM
How the blaster worm was spread.
72
SOAP
Replacement for DCOM-uses XML based comms.
73
CORBA
1. Common Object Request Broker Architecture. 2. Standard developed by Object Management Group which allows different applications written in different languages to communicate. 3. Standard set of interfaces and API’s for systems to use to communicate with other ORB’s.
74
Component Object Model (COM)
1. Architecture to allow simple inter-process comms between objects. 2. Allows objects on one system to communicate.
75
Distributed Component Object Model (DCOM)
1. Allows for COM inter-process communication in a distributed form. 2. Allows objects on different systems to interact. 3. Works as middleware for distributed processing.
76
Linking through COM - OLE
Object Linking and Embedding: 1. Provides a way for objects to be shared on a local workstation and uses COM as its foundation base. 2. Allows objects to be embedded into documents (i.e. graphics, pictures, and spreadsheets). 3. Linking is the capability for one program to call another. 4. The capability to put a piece of data inside a foreign program or document is embedding.
77
Mobile Code - Active Content
!. Documents or scripts that can carry out actions without user intervention.2. Increase user functionality through a browser. 3. Java applets, Java Script, ActiveX controls, macros and executable e-mail attachments. 4. Extend capabilities and functionality, but can introduce more risks. 5. Trojan horse, backdoors, viruses, malicious code, and worms all take advantage of Active content.
78
World Wide Web OLE - ActiveX
1. Platform specific and language dependent. 2. ActiveX controls communicate to objects using COM services. 3. Outgrowth of OLE and COM technologies for the WWW.
79
ActiveX Controls
1. Is MS technology that is used to write controls that Internet users can download to increase their functionality and user experience. 2. Extension of OLE. 3. Security scheme: inform user of the origin of the componentt who will decide if it should be trusted. 4. Security relies on digital certificates and trusting certificate authorities.
80
Java
1. Language developed by Sun. 2. Object-oriented, platform-independant programming language. 3. Runs on top of the Java VM which allows applets to run on several different platforms. 4. Uses byte-code instead of being compiled directly into machine code.
81
Java Applets
1. Small Java programs that run within a users browser. 2. Mobile code that is restricted from accessing loval disks and network connections by being contained in a sandbox. 3. Several bugs within Java code allow malicious code to escape the sandbox and perform malicious acts.
82
Common Gateway Interface (CGI)
1. CGI is a method of manipulating data passed into a website. 2. CGI script resides on web server, not the browser. 3. Allows for interactive Websites that process user input. 4. Security risks are that they use an array of low level system commands that can be exploited. 5. Scripts are interpreted and not compiled-there is more a risk of it being modified. 6. The CGI scripts should
83
Web Applications - Input Validation
1. Web forms can be a source of attack if special characters or code is allowed to be entered. 2. Developers must check input parameters and perform “inout cleansing” before the form is submitted to the server.
84
Web Applications - SQL Injection
1. When SQL statements are entered into a form. 2. Allows attacker to manipulate the database tier of a web application.
85
Web Applications - Cross Site Scripting
1. JavaScript is entered through a form or url parameter. 2. Comes back around to the victims browser and executes. 3. Commonly found in the URLs within phishing emails.
86
Cookies
1. HTTP cannot track web users and their actions. 2. Cookies can allow sites to “remember” users visits and choices - tokens within HTTP requests and responses. 3. Can be per session. 4. Can be persistent. 5. Privacy issues - collect personal information about users and can contain sensitive information that an attacker may try to access.
87
Malware
1. Virus. 2. Worm. 3. Logic Bomb. 4. Trojan Horse. 5. Other attack types.
88
Malicous Code Detection
1. File size increase. 2. Many unexpected disk accesses. 3. Change in update or modified timestamp. 4. Sudden decrease of hard drive space. 5. Calculating checksums on system files. 6. Unexpected and strange activity by applications.
89
Malware types - Virus
1. A virus is a program that searches out other programs and infects them by embedding a copy of itself.
90
Types of Viruses
1. Macro Viruses: easy to create because of the simplicity of the macro languages. 2. Boot sector virus: malicious code inserted into the disk boot sector. 3. Compression virus: when decompressed, it initializes and attacks the host system. 4. Stealth virus: hides its forrprints and changes that it has made.5. Plymorphic virus: makes copies and changes the copies in same way - uses a mutation engine. 6. Multi-partite virus: infects both boot sector and hard drive (the file system).
91
Malware types - Virus - Worms
1. Can reproduce on their own - different than virus. 2. Self contained programs.
92
Malware types - Virus - Logic Bomb
An event triggers the execution of specific code.
93
Malware types - Virus - Trojan Horse
1. Program disguised as another program. 2. Useful program that contains hidden code exploiting the authorization of process to violate security.
94
Attack types - Smurf
1. ICMP Echo broadcast is sent to a network with a spoofed address. 2. All systems on network segment send ICMP Echo Reply packtes to the victim. 3. DoS attack.
95
Attack types - Fraggle
1. Same as SMURF. 2. Uses UDP instead of ICMP protocol.
96
DDOS
Distributed Denial of Service: 1. Committing resources on a computer so that it cannot respond to valid requests. 2. Can be distributed and amplified by using other systems to commit the attack - DDoD (Masters and Zombies and Handler Systems).
97
DDoS - Handlers and Zombies
Comprise BotNet. Common DDoS attacks are Tribal, trin00 and TFN.
98
DDoS Countermeasures
1. Drop all ICMP packets originating from the Internet. 2. Drop any requests to broadcast addresses. 3. Ingress filtering: do not allow packets to leave with external source addresses.
99
Salami Attack
Taking insignificant pieces of data, say pennies, from a user’s bank account and moving them to the attacker’s account.
100
Session Hijacking and Man in the Middle (MITM)
Capturing a session just prior to the user signing off an attacker could use the existing credentials to continue accessing and altering data.
101
Artificial Intelligence - Expert Systems
1. A computer program containing a knowledge base and set of algorithms and rules. 2. Used to infer new facts from existing knowledge and incoming data. 3. Uses AI to mimic human logic. 4. Data is collected from human experts and stored in a dbase-collected data is used for problem solving and best when working with a limited domain of data.
102
AI - Inference Engine - Rule-based programming
1. Rules are based on “if - then” logic units. 2. This specifics a set of actions to be performed for a given situation. 3. Uses human logic.
103
AI - Inference Engine
1. The engine matches facts against patterns and determines which rules are applicable. 2. The engine can find patterns not obvious to humans and then it can apply human logic.
104
Artifical Neural Networks
1. Electronic model based on the neural structure of the brain. 2. ANN systems have: a. the ability to remember and learn from new experiences b. the capacity to generalize. 3. Decisions by neural networks are only as good as the experiences they are given.
