Security Architecture and Engineering Flashcards
ISO 15288
Common for processes
TECHNICAL PROCESSES
Business and mission analysis process
Stakeholder needs and requirements definition process
System requirements definition process
Architecture definition process
Design definition process
System analysis process
Implementation process
Integration process
Verification process
Validation process
Operation process
Maintenance process
Disposal process
TECHNICAL MANAGEMENT PROCESSES
Project planning process
Project assessment and control process
Decision management process
Risk management process
Configuration management process
Information management process
Measurement process
Quality assurance process
ENABLING PROCESSES
Lifecycle model management process
Infrastructure management process
Portfolio management process
Human resources management process
Quality management process
Knowledge management process
SYSTEM AND SECURITY ENGINEERING PROCESSES
Commonly accepted sources for engineering processes:
International Council on Systems Engineering (INCOSE)
NIST SP800-160 System Security Engineering
ISO/IEC 15026 series-System and Software Engineering
ISO/IEC/IEEE 15288 Systems and Software Engineering
Systems and systems engineering processes have converged across major sources:
NIST and INCOSE recognize system security engineering as a specialty engineering function
AGREEMENT PROCESSES
Acquisition process
Supply process
KEY PRINCIPLES OF SYSTEM SECURITY
Confidentiality
Integrity
Availability
SECURITY MODELS
Purpose: the security models define rules of behavior for an information system to enforce policies related to system security but typically involving confidentiality and/or integrity policies of the system
BELL-LPADULA (BLP) MODEL
CONFIDENTIALITY MODEL
State machine level
Developed for the Department of Defense (DOD)
Used for multilevel security (MLS)
3 Properties defined:
No read-up (simple security property)
No write-down (star property)
Access matrix (discretionary property)
BIBA MODEL
INTEGRITY
State transition model
Focus on integrity vice confidentiality
Opposite rules from VBell-LaPadule (BLP)
Can read up (simple integrity property)
Can write down (star integrity property)
Lower level process cannot request higher access (invocation propoerty)
BREWER AND NASH MODEL
CONFIDENTIALITY
Designed to prevent conflict of interest
Information flow control model
Decomposes a company’s information into discrete datasets based on potential conflicts of interest
Defines rules for acceptable access to data objects by a particular subject(e.g person or process)
Accessing a data object excludes future access to potential conflict of interest objects
CLARK-WILSON MODEL
INTEGRITY
Introduces the concept of triples:
Subject
Program
Object
Subjects can only manipulate data objects though the use of a defined program
Set of rules designed to ensure data integrity for all operation
GRAHAM-DENNING (MODEL
CONFIDENTIALITY + INTEGRITY
Set of rules for creation, assignment of access rights, and deletion of objects and subjects
Eight rules (create/delete object/subject, assign, read, grant, delete, and transfer access rights)
Often used in distributed systems
HARRISON RUZZO ULLMAN (HRU)
INTEGRITY
Primarily for protection of access rights integrity
Confidentiality is protected by access rights, so HRU does provide secondary confidentiality protection
Extends Graham-Denning model
Defines a set of primitive allowable operations involving subjects and objects
AVAILABILITY MODELS
THERE ARE NONE
SECURITY CONTROLS
Safeguards or countermeasures that mitigate risks to confidentiality, integrity and availability in a system or operating environment
Controls may impact or modify the behavior of people, process or technology
TYPE OF CONTROLS
PREVENTATIVE - reduce the likelihood o impact of an undesirable event from happening.
DETECTIVE CONTROLS - identify an undesired event or collect information about it
CORRECTIVE CONTROLS - reduce or eliminate the impact of an undesirable event that has occurred
MEANS OF APPLICATION:
MANAGEMENT - policy or human driven controls
OPERATIONAL - process-driven controls
TECHNICAL - controls applied to technology
COMMON/INHERITABLE CONTROLS
Exist outside of a particular system but to provide some confidentiality, integrity and availability (firewall inherited by systems behind a firewall)
May include management, operational or technical controls
CONTROL SELECTION
Controls are selected to support the confidentiality, integrity and availability needs of the system
Control frameworks are often utilized to select appropriate controls and define controls
Inheritable controls that support the system are identified
CONTROL FRAMEWORKS
They define controls and control elements
frameworks allow for standardization of control implementation
Control frameworks often include evaluation criteria or mechanisms to verify controls are effective
EXAMPLE OF CONTROL FRAMEWORKS
ISO 27001 - industrial standard
NIST (SP800-52) - required for government use
COBIT - focused on business values
ISA/IEC 62443(ISA 99) - industrial automation and control systems
TAILORING CONTROLS
Control frameworks and standards are intended to be tailored to specific use-cases
Adjust control specifications or parameters to meet the needs of a specific system or environment
“Book” controls must be tailored to provide optimum value
Controls are not intended to be used as a checklists
EVALUATION CRITERIA
Each control should include specific evaluation methods and expected results
NIST Example:
TEST - coduct a direct test of the control
INTERVIEW - interview or question staff
EXAMINE - examine documentation or artifacts for evidence the control is properly employed
CONTROLS MAY BE EVALUATED BY MULTIPLE METHIDS
SYSTEM SECURITY CAPABILITIES
Access Control
Processor States
Memory Management
Process Isolation
Data Hiding
Abstraction Layers
Security Kernel
Encryption
Code Signing
Audit and Monitoring
Virtualization/ Sandbox
Hardware Security Modules
File System Attributes
GENERIC OPERATING SYSTEM (OS) MODEL
Application APPLICATION APPLICATION
API Services User Interface
Security Monitor Memory Mgr. Process Mgr.
I/O Mgr. Device Drivers Hardware Abstr. Layer
HARDWARE Trusted Platform Module (TPM)
TRUSTED PLATFORM MODULE
Encryption
REFERENCE OR SECURITY MANAGER
Theoretical
ACCESS CONTROL
OS controls access to objects
Rules defined allowable behavior
Security monitor or reference monitor enforces allowed behavior
File systems typically support by assigning security attributes to objects/files
PROCESSOR STATES
Processors typically support at least two states of operation: user and kernel modes.
User mode has limited access to ore functions or direct hardware access
MEMORY MANAGEMENT
Direct application access to system memory is restricted
Modern operation systems randomize memory location (address space)
Modern operating systems limit memory locations where code can execute - for example:
Data Execution Prevention (DEP) in Windows
PROCESS ISOLATION
Processes execute in separate memory space
Direct exchanges between processes is limited
Operating system (OS) manages inter-process exchanges through controlled interfaces
DATA HIDING
Typical with multi-level security (MLS) architectures using mandatory access control (MAC)
Data or objects at a higher security level cannot be seen by objects at a lower security level (BLP Model)
Also a coding practice where raw data is hidden from access and can only be obtained from a standardized interface.
ABSTRACTION LAYERS
Limits direct access to objects or entities
Defines allowable actions and interactions between layers
Protects against improper behavior or access between layers
SECURITY KERNEL
Also known as reference monitor
“Big brother” of kernel mode
Monitors and validates access control over system objects
Enforcement and validation component of all secure operating systems
REFERENCE MONITOR
Theoretical set of system tools which independently verify the actions of a system from a security standpoint.
Trusted Platform Module (TPM)
Hardware which provides cryptographic information and functions to enable the management and communications of sensitive information
ENCRYPTION
Can be applied to data at rest (hard-drive files) or in transit (communication channel)
May protect confidentiality and/or integrity of data
Protects data when OS features (security kernel) are not active or present
for example - Bitlocker protects data when the OS is not running
CODE SIGNING and VALIDATION
Cryptographic function
Executable code is digitally signed
OS validates signature before loading code
Unsigned code or code with a invalid signature is prevented from executing
May include OS internal code to prevent placement of OS components
AUDIT AND MONITORING
System actions are recorded and stored in a protected location
Specific actions that are recorded are typically customized
Audit records MUST be reviewed or monitored to be effective
Monitoring and review may include both automated and manual elements
Audit records are typically transferred off a system for protection and long term storage
VIRTUALIZATION / SANDBOX
Executing code is”wrapped” in a virtualization or sandbox layer
Code executing within the environment is strictly limited from direct interaction outside the environment
Permissions for a system access may be restricted independently for each virtualized or sandbox instance
May be an OS native function or function provided by a third party software
HARDWARE SECURITY MODULES
Hardware components that provide security services
Trusted Platform Module (TPM)
most common security module
provides secure storage and crypto functions
typically used to generate and store crytpo keys
keys or stored data cannot be accessed without permissions
Specialized modules may contain multiple hardware security modules
