Term
| Software Security Issue: Connectivity |
|
Definition
| Asks for the minimum number of elements (nodes or edges) which need to be removed to disconnect the remaining nodes from each other. It is closely related to the theory of network flow problems. It is an important measure of its robustness as a network. |
|
|
Term
| Software Security Issue: Complexity |
|
Definition
| Used to characterize something with many parts in intricate arrangement. |
|
|
Term
| Software Security Issue: Extensibility |
|
Definition
| A system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. |
|
|
Term
| Software Security Issue: Provenance |
|
Definition
There are two main aspects regarding the ownership of data and data usage. Ownership will tells the user who is responsible for the source of the data, ideally including information on the originator of the data. Data usage gives details regarding how the data as been used and modified and often includes information on how to cite the data source or sources. Data provenance is of particular concern with electronic data, as data sets are often modified and copied without proper citation or acknowledgement of the originating data set.
Note: Securing this area mean to provide integrity and confidentiality guarantees regarding data owernship and usage. In other words, it means to ensure that history cannot be rewritten. |
|
|
Term
| Software Security Issue: Treat Environment |
|
Definition
The body of threats considered applicable to a given system. Example: STRIDE model.
1. Spoof
2. Tamper
3. Repudiate
4. Information disclosure
5. Denial of service
6. Elevation of privilege. |
|
|
Term
| Vulnerability Class: Incomplete parameter validation |
|
Definition
Input parameters not validated for type, format, and acceptable values.
|
|
|
Term
| Vulnerability Class: inconsistent parameter validation |
|
Definition
Input validation does not follow consistent scheme, i.e,
parameters may not be validated with the right criteria.
|
|
|
Term
| Vulnerability Class: Implicit sharing of privileged/confidential data |
|
Definition
Resources are not appropriately segregated, e.g.,
put a confidential document on a common drive that lots of people who are not cleared have access to.
|
|
|
Term
| Vulnerability Class: Asynchronous validation/inadequate serialization |
|
Definition
Vulnerabilities resulting from concurrency, sequencing of events as in message queue systems.
|
|
|
Term
| Vulnerability Class: Inadequate identification/authentication/authorization |
|
Definition
Access control vulnerabilities, e.g., having generic passwords, not following the principle of least privileges
|
|
|
Term
| Vulnerability class: violable prohibition/limit |
|
Definition
| Lack of enforcement on resource limitations, such as buffer overflows |
|
|
Term
| Vulnerability Class: Exploitable logic error |
|
Definition
Program logic errors enabling circumvention of access control; e.g.,
if a <= 3 but should have been "if a < 3".
|
|
|
Term
| Systems Development Life Cycle (SDLC) (definition) |
|
Definition
| A process of creating or altering information systems, and the models and methodologies that people use to develop these systems. |
|
|
Term
| Systems Development Life Cycle (SDLC) (traditional parts of) |
|
Definition
1. Requirements and use cases.
2. Architecture and design.
3. Test Plans.
4. Code.
5. Tests and test Results.
6. Feedback from the field. |
|
|
Term
| SDLC: Phase 1a: Use Cases: Security Concerns |
|
Definition
Use cases should include things that are not supposed to happen, such as by pass, tampering, role escalation attempts, covert channels, overt channels, etc. |
|
|
Term
| SDLC: Phase 1b: Requirements: Security Concerns |
|
Definition
Security requirements should reflect considerations for system preservation, and also include functional requirements designed to avoid fraud and misuse, such as segregation of duties to ensure collaboration is required to commit crimes with software and audit trails to the extent necessary to trace individual activity. |
|
|
Term
| SDLC: Phase 4: Code Review: Security Concerns |
|
Definition
Code review should be both manual and automated. Automated code review should be both static and dynamic, static looks for patterns, dynamic follows code memory in execution. |
|
|
Term
| SDLC: Phase 5: Tests and Test Results: Security Concerns |
|
Definition
Penetration testing should cover both black box scanning and authorized user escalation techniques, it should also include fuzzing. |
|
|
Term
| Fuzz Testing, i.e., fuzzing |
|
Definition
| A software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random data to the inputs of a computer program. The program is then monitored for exceptions such as crashes or failing built-in code assertions. Fuzzing is commonly used to test for security problems in software or computer systems. |
|
|
Term
| Software Bug (definition) |
|
Definition
| Implementation level problem; e.g., if < 3 should have been if <= 3 |
|
|
Term
| Software Flaw (definition) |
|
Definition
|
|
Term
|
Definition
A security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites.
It typically provides a tightly-controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted. |
|
|
Term
| Sandbox (pluses/limitations) |
|
Definition
Plus: Prevents attacker from installing arbitrary code.
Limitation: Does not address phishing; circumvention of firewalls by compromised brower; protection of web sites from their vulnerabilities. |
|
|
Term
|
Definition
| A way of attempting to acquire information such as usernames, passwords, and credit card details by masquerading as a trustworthy entity in an electronic communication. |
|
|
Term
| Inter-process communication (IPC) |
|
Definition
| A set of methods for the exchange of data among multiple threads in one or more processes. |
|
|
Term
|
Definition
• Software that monitors software • Relies on segregation of resources and administrative activity • Visualized as a loop monitoring a loop |
|
|
Term
| Public Key Infrastructure (PKI) |
|
Definition
– Defines the relationship between the entities (root CA, subordinate CAs, organizations, and users) of a secure communication system based on public-key cryptography – Provides a systematic method of issuing and managing digital certificates – Provides a centralized method of locating other users’ public keys – Greatly reduces the likelihood of MIM attacks |
|
|
Term
|
Definition
| The process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash. |
|
|
Term
|
Definition
| An electronic document which uses a digital signature to bind a public key with an identity — information such as the name of a person or an organization, their address, and so forth. It can be used to verify that a public key belongs to an individual. |
|
|
Term
| Process for validating a digital certificate |
|
Definition
Certificate validation follows these steps: • Verify the signature attached to the certificate • Check the validity period of the certificate • Process any certificate extensions • Identify any policy or usage constraints • Ensure that the certificate has not been revoked |
|
|
Term
|
Definition
– Establishes the relationship between a CA and the individuals and organizations to which that CA issues digital certificates |
|
|
Term
| Role of a Certificate Authority (CA) |
|
Definition
• Responsible for:
– Issuing digital certificates to end-entities or subordinate CAs – Authenticating certificate requests prior to issuing certificates – Managing the certificate lifecycle, which includes certificate creation, issuance, distribution, storage, renewal, and revocation – Defining and enforcing the PKI trust hierarchy (i.e., the relationship between the entities within the PKI) |
|
|