Types of Security Requirements Flashcards
Core Security Requirements
Confidentiality, Integrity, Availability, Authentication, Authorization, Accountability
General Security Requirements
Session Management, Error/Exceptions Management, Configuration Parameters Management
Operational Security Requirements
Deployment environment, Archiving, Anti-piracy
Other Security Requirements
Sequencing & Timing, International, Procurement
Confidentiality Requirements
address protection against the unauthorized discplosure of data or information that are private/sensitive
Data classification
public (directory), non-public
Confidentiality controls
secret writing (i.e. overt and covert), and masking
Secret writing goal
to prevent the disclosure of the information deemed secret, includes overt cryptographic mechanism (encryption and hashing) or covert (steganography, digital watermarking - e.g. hinding)
Describe covert
steganography is invisible writing (camuflaging - military spionage), digital watermarking is embedded information in audio, video or pictures - used for copyright, deterring and preventing unauthorized copying of media.
Masking
This is primarily used to protect against shoulder surfing attacks, which are characterized by someone looking over another’s shoulder and observing sensitive information (e.g. hiding password when typing, last 4 creditcard numbers).
non-public data state
In transit (transmitted), In processing (held in computer memory or media for processing), Storage (at rest)
time bound confidentiality
some information may require protection only for a certain period of time (e.g. during merge or acquisition)
Integrity requirements
address two primary areas of software security (reliability and protection/prevention) against unauthorized modifications
Integrity refers to
system integrity and data integrity
data integrity
information and programs can be changed only in a specified and authorized manner by authorized personnel.
Example system integrity violation
SQL Injection that makes the software act or respond in a manner not originally designed.
Integrity security controls
input validation, CRC and hashing
Input validatoin check
provides a high degree of protection against injection flaws and provides both system and data integrity.
CRC
useful in the detection of errors or changes made to data when it is transmitted.
Hashing
mainly used for integrity assurance, it can also provide confidentiality assurance
Availability requirements
ensure the protection against destruction of the software system and/or data, thereby assisting in the prevention against DoS to authorized users.
MTD
Maximum Tolerable Downtime - measure of the maximum amount of time that the software can be in a state of not providing expected service
RTO
Recovery Time Objective - amount of time by which the system or software needs to be restored back to the expected state of business operations for authorized business users
RPO
the maximum allowed data or productivity loss when the system becomes disrupted or down
BIA
Bussiness Impact Analysis - determine the adverse impact that the unavailability of software will have on business operations
Authentication requirements
verify and assure the legitimacy and validity of the identity (a person, a process, a hardware device) that is presenting entity claims for verification.
authentication credentials
different factors or a combination of factors that include knowledge, ownership or characteristics.
authentication forms
anonymous, basic, digest, integrated, client certificates, forms, token, smart cards, biometrics
basic authentication
HTTP - client browser prompting the user to supply their credentials.
digest authentication
challenge/response mechanism - send a message digest (hash value) and compare the hash values of what was previously established
integrated authentication
NT challenge/response authentication, implemented in standalone authentication mechanism or in conjunction with Keberos authentication.
client certification-based authentication
validate the identify of the certificate holder. the current standard for digital certificates is ITU X.509
forms authentication
users to supply username and password for authentication purposes - it is advisable to first cryptographically protect the data being transmitted in addition to implementation transport layer security (TLS) such as SSL or network layer security such as IPSec
OTP
One Time (dynamic) passwords (OTP) provide the maximum strength of authentication security and OTP tokens (also known as key fobs) require two factors, knowledge (something you know) and ownership (something you have).
FIPS 201
Personal Identity Verification standard provides guidance that the enrollment data in systems implementing biometric based authentication needs to be changed periodically
Biometric - Type I error
False Rejection error where a valid and legitimate enrollee is denied (rejected) access
Biometric - Type II error
False Acceptance error where an imposter is granted (accepted) access.
CER
Crossover Error Rate - used in evaluating different biometric devices and technologies (more accurate means low CER)
Authorization requirements
confirm that an authenticated entity (human, process, hardware) has the needed rights and privileges to access and perform actions on a requested resource
Subjects
entities (human user, system process) that are requesting access
Objects
items that subject will act upon.
Actions
CRUD - Create, Read, Update or Delete data
DAC
Discretionary Access Control - restricting access to objects based on the identity of subjects and/or groups to which they belong
NDAC
Non-Discretionary Access Control - it is unavoidably imposed on all subjects
MAC
Mandatory Access Control - access to objects is restricted to subjects based on the sensitivity (represented by a label) of the information contained in the objects. All objects shall have a sensitive label. it is based on multilevel security requirements.
RBAC
Role-Based Access Control - Roles are defined by job function which can be used for authorization decisions. Roles define the trust levels of entities to perform desired operations. Access that is granted to subjects is based on roles. The resource is directly mapped to the role.
Resource-BAC
Resource-Based Access Control - useful in architectures that are distributed and
multi-tiered including service oriented architectures (users are unknown)
RBAC Separation of duties
no individual can be assigned to two roles that are mutually exclusive in their permissions to perform operations.
RBAC benefit
Simplified subjects and objects access rights administration, Ability to represent the organizational structure, Force enterprise compliance with control policies more easily and effectively.
Impersonation and Delegation Model
Resource-BAC: Allowing a secondary entity to act on one’s behalf is the principle of delegation. Kerberos uses the delegation and impersonation model where the user upon successful authentication is granted a Kerberos ticket and the ticket is delegated the privileges and rights (sets of permission) to invoke services downstream.
Trusted Subsystem Model
Resource-BAC: access request decisions are granted based on the identity of a resource that is trusted instead of user identities.
Accountability Requirements
assist in building a historical record of user actions. Auditing requirements not only help with forensic investigations as a detective control but can also be used for troubleshooting errors and exceptions.
General Requirements, Session Management Requirements
ensure that once a session is established, it remains in a state that it will not compromise the security of the software.
Session management requirements
assure that sessions are not vulnerable to brute force attacks, predictability or Man-in-the-middle hijacking attempts
General Requirements, Errors & Exception Management Requirements
ensure that errors and exceptions are explicitly addressed.
Errors & exceptions
potential sources of information disclosure, verbose error messages and unhandled exception reports can result in divulging internal application architecture, design and configuration information
improper error or exception management
using laconic error messages and structured exception handling are examples of good security design features that can thwart security threats posed.
General Requirements, Configuration Parameters Management Requirements
makeup the software needs protection against hackers - these parameters and code usually need to be initialized before the software can run.
Operational Requirements
requirements that impact the most efficient operations of the software itself such as Deployment environment, archiving, anti-privay.
Other requirements
Sequencing & Timing, International, Procurement
Operational Requirements identify
the needed capabilities and dependencies of the software as it serves the business with their intended functionality (CONOPS is a start point).
Deployment Environment Requirements
identify and capture pertinent requirements about the environment such as ports and protocols are available, deployed in an Internet, Extranet or intranet environment, software need to support single sign-on (SSO)
authentication, …
Deployment Environment Requirements Importance
Identifying and capturing constraints, restrictions and requirements of the environment in which the software is expected to operate alleviate deployment challenges later
Archiving Requirements
maintained either as a means for business continuity or as a need to comply with a regulatory requirement or organizational policy.
Archiving information
determine location, duration and format. Some questions: where data will be stored, how much space, ensure media is not re-writable, how fast to retrieve, …
Anti-Piracy Requirements
Code obfuscation, code signing, anti-tampering, licensing and IP protection mechanisms should be included as part of the requirements documentation especially
Sequencing and Timing Requirements
it concerns to design flaws in software that can lead to what is commonly known as race conditions or Time of Check/Time of Use (TOC/TOU) attacks. E.g. undesirable sequence of events, infinite loops and Multiple unsynchronized threads executing simultaneously for a process
International Requirements
(i) Legal requirements are those requirements that we need to pay attention to so that we are not in violation of any regulations;
(ii) Technological requirements for instance Character encoding and display direction are two important international software requirements that need to be determined (e.g. unicode, UTF-32).
Procurement Requirements
when procure the software instead of building
it in-house, it is important to include software security requirements in legal protection mechanisms such as contracts and SLAs.
