---
title: "CISSP Domain 3-1: Security Architecture and Engineering"
description: "CISSP Domain 3-1: Security Architecture and Engineering"
keywords: "CISSP, Domain 3-1, Security Architecture, Engineering, Cryptography"
author: "diabee"
date: "2025-01-21"
---
## CISSP Domain 3: Security Architecture and Engineering

### Research, implement and manage engineering processes using secure design principles (3.1)

#### Secure Design Principles

- Secure design principles evolve from security needs.
- Many reflect due care and due diligence based on best practice in the field.
- No single design approach fits all situations or needs.
- Most information security controls combine multiple design principles.

#### Basic Secure Design Principles

- Least Privilege
- Least privilege is the practice of granting a user the minimum permissions necessary to perform their explicit job function. This does not mean that a user will have low permission. If the user is a system administrator, for example, then they will need a privileged account to do their jobs. If the user is a senior VP in the company, they do not need to have a privileged account in order to do their job, so they will not have such permissions, even though the VP is a trusted individual.
- Need to know (因<font color='yellow'>需</font>可知) →
- 需
- 授權/層級
- 需要

- Separation of Duties (SoD)
- 職責分離 → 銀行跑流程雙簽章例子
- Separation of duties (SoD) means that a sensitive process cannot be completed by a single person, process or system. This means that some form of checks and balances provide at least two independent means to verify that the action is authorized at that time to use the data or other systems assets and resources involved, and that the people or processes involved are authorized to do so. The SoD concept is intended to reduce the possibilities of corruption and theft. When a single individual can perform an entire trust process with no limitation, the chances of that individual performing fraudulent activities or embezzling trust increases, and the chances of identifying said activity are reduced. An example process is that of procurement. With no SoD, a manager can receive a single quote, create a purchase order, issue a check and purchase the product based solely on his or her decision. In such a scenario, it is easy for the manager to embezzle trust. However, in a controlled process, the purchasing manager must sign the purchase order that will be processed by the accountant, who can issue the check but only with a purchase order signed by a manager.As with all security measures, SoD necessarily degrades the efficiency of operations but with the benefit of making the process more secure.
- Secure Defaults
- When designing a system to be secure in default, the default configuration settings of the system should be the most secure settings possible, even if this configuration negatively affects user experience. In many cases, security and user friendliness are evaluated based on both risk analysis and usability tests, and balance between them is required to maintain security requirements while achieving business goals. As security professionals, we should advise and insist on secure defaults both when we are on the vendor side as well as the customer side.
- Fail Secure/Close
- 故障安全機制 (金庫索、防火牆)
- 當故障發生情況下，我要保持安全性
- When a system is designed to fail securely, it will fail in a secured manner by default if there is a system crash, reducing potential data exposure and other security risks. A fail-secure approach is relevant when designing a system with high exposure potential. When designing a system with a fail-secure approach, consideration of human safety must be addressed as well. For example, when designing fire evacuation procedures of a sensitive facility, it is imperative to ensure human safety is considered first, even at the expense of potential exposure of sensitive data to said personnel.
- Fail Safe/Open
- 故障保險機制(門禁管控機制)
- 當故障發生情況下，不對人造成傷害

- Shared Responsibility
- cloud(u-bike)
- 雲端業者會有責任，每個人都會有自己的責任在裡面
- The explosive growth of cloud services over the past decade, with businesses moving core functions to an external service provider, means maintaining security and compliance must be a shared responsibility of the provider and the customer. Shared responsibility is required because the customer cannot control everything that happens in the cloud environment; furthermore, it is also impossible to place all responsibility at the provider level, since the cloud provider does not control the actual data that is stored on the cloud, and how it is used, and thus cannot hold all the responsibility. This means that in order to maintain an adequate level of privacy and security, both sides must do their part and maintain security in accordance with defined terms of agreement. Typically, the contract between service providers and their customers (often called a service-level agreement or SLA) is used to clearly identify which responsibilities are exclusive to which party, and which are shared.
- Keep it Simple
- 越複雜的東西，越要簡單設計
- 複雜的情況下
- 沒有辦法有效驗證/檢查安全性
- 故障排除會很困難

- Trust but Verify
- Access Control(3A)
- Authentication
- Authorization
- Accounting
- Traditional security concepts based on DiD have long relied on a single authentication of a user (human or nonhuman) as they enter the systems environment. Once authenticated, they can freely roam about the building, the campus, or the internal networks and systems. Sensitive resources would be further protected by permissions enforced by authorization checks, but without additional firewalls or security boundaries, no further authentication checks (to see if the user ID is who or what it claims to be) would be done. Many small organizational local area networks (LANs) operate with a Trust but Verify posture.
- Zero Trust
- 每一次存取都做檢查、確認
- This concept recognizes that once inside a trust but verify environment, a user has perhaps unlimited capabilities to roam around, identify assets and systems and potentially find exploitable vulnerabilities. By placing a greater number of firewalls or other security boundary control devices throughout the network, the number of opportunities to detect a troublemaker before harm is done is increased. Many enterprise architectures are pushing this to the extreme of microsegmenting their internal networks, which enforces frequent re-authentication of a user ID.

- Privacy by Design
- Privacy by design is a system design approach published in 2009 by Ann Cavoukian, thenInformation and Privacy Commissioner of Ontario, Canada. The concept aims to assure that maintaining privacy is considered throughout the design and development stages of a system. The concept was adopted by the GDPR, the U.S. FTC, the Commissioner for Privacy and Data Protection (CPDP), the Victorian public sector (Canada) and other regulators around the world. The adoption of the concept goes hand in hand with the increased emphasis on maintaining privacy in global legislation.

- Defense in Depth
- Defense in depth (DiD) was first introduced as a concept in information security by the National Security Agency (NSA) in the U.S. It uses a layered approach when designing the security posture of an organization and is sometimes referred to as the castle model. Think about a castle that holds the crown jewels. The jewels will be placed at the heart of the castle in a vaulted chamber guarded by security guards. The castle is built around the vault with additional layers of security in each layer—soldiers, walls, a moat. The same approach is true when designing a secured facility or system. Using layers of security will deter possible attackers and send them to focus on other, easier targets.

#### Defense in Depth

- 系統層次拉出來
- Not 變成 Many Control Defense，會取決你最弱的那一環
- 木桶理論，利用高矮不一的木板組起來，木桶的容納水的取決你最短的那根木頭，many control defense 的問題
- 若是做到DiD，會取覺你最強的那一環

### Understand the fundamental concepts of security models (3.2)

#### Access Control System (Domain 5)



- Reference Monitor →負責扛security

#### Security Models

- Security models describe the security properties of an AC policy
- Define rules of behavior that AC mechanism follows to enforce
access control policies related to system security
- Address confidentiality, integrity policies

#### Security Models

- Bell–LaPadula (BLP)
- The Bell–LaPadula (BLP) model addresses confidentiality in a multilevel security (MLS) system. It defines two primary security constructs: subjects and objects. Subjects are the active parties, while objects are the passive parties. To help determine what subjects will be allowed to do, they are assigned clearances that outline what modes of access (e.g., read, write) they can use when they interact with objects.
- The BLP model system uses labels to keep track of clearances and classifications and implements a set of rules to limit interactions between different types of subjects and objects. It was an early security model and does not provide a mechanism for a one-to-one mapping of individual subjects and objects, which is a fundamental requirement for building a practical OS.
- 機密性模型，機密性控管
- 多層次安全系統→ 同一個等級的存取是沒有限制
- 跨等級去存取

- Read down Write up的Model，藉由這個方式去維持機密性

- Read up → 就有人洩密
- Write down → 我洩密
- ss property: Simple Security property(read down)
- Simple Security property. A subject with this property cannot read/access an object of a higher classification (i.e., no read up).
- *s property : Star property(write up)
- A subject with this property can only save an object at the same or higher classification (i.e., no write down).
- 參考例子
- https://blog.csdn.net/sinat_36082782/article/details/104506721
- https://ppfocus.com/0/hob5927da.html

- Biba
- The Biba model addresses data integrity; it does not address data confidentiality. Like the BLP model, Biba is a lattice-based model with multiple levels. It defines similar but slightly different modes of access than the BLP model (e.g., Biba uses observe and modify; BLP uses read and write). Like the BLP model, the Biba model describes interactions between subjects and objects. Where the Biba model differs most obviously is that it is an integrity model; it focuses on ensuring that the integrity of information is being maintained by preventing corruption.
- At the core of this model is a multilevel approach to integrity designed to prevent unauthorized subjects from modifying objects. Access is controlled to ensure that objects maintain their current state of integrity as subjects interact with them. Instead of the confidentiality levels used by the BLP model, the Biba model assigns integrity levels to subjects and objects depending on how trustworthy they are. Like the BLP model, the Biba model considers the same modes of access but with different results.
- Integrity
- Read up Write down的模型


- 當安全比你高，代表資料比你正確
- Read up → 當然看安全性高的人
- Simple Integrity property. A subject with this property cannot read or observe an object of lower integrity (i.e., no read down).
- Write down → 會把比較正確給安全性低的人
- Star property. A subject with this property cannot modify an object of higher integrity (i.e., no write up).
- Invocation property. A subject with a lower integrity level cannot request access to a higher integrity level object, only to objects at an equal or lower integrity level.
- 你不能去呼叫安全性比你高的程式，只能執行安全等級比你低或相同。因為怕你搞壞他的資料。

- Brewer and Nash

- The Brewer and Nash model focuses on preventing conflict of interest when a given subject has access to objects with sensitive information associated with two competing parties. The principle is that users should not access the confidential information of both a client organization and one or more of its competitors. At the beginning, subjects may access either set of objects. Once a subject accesses an object associated with one competitor, they are instantly prevented from accessing any objects on the opposite side. This is intended to prevent the subject from sharing information inappropriately between the two competitors, even unintentionally. Such ethical walls are also frequently used in financial services organizations, for example, to prevent corporate advisory services isolated from brokerage services; this reduces the opportunity and the temptation to abuse insider information in ways that would violate both laws and ethics. It is an unusual model in comparison with many of the others because the access control rules change based on a subject’s behavior.
- Chinese wall
- 為了避免利益衝突，魚與熊掌不能兼得

- Ａ和B是競爭客戶，此人是A和B的顧問，所以會有得知A的內容有可能告訴Ｂ，所以必須設下Chinese Wall。我服務了Ａ就不可以服務B。
- Ex:律師是被告人的律師就不會是告人的律師
- Confidentiality

- Clark-Wilson
- The Biba model only addresses one of three key integrity goals. The Clark–Wilson model improves on the Biba model by focusing on integrity at the transaction level and addressing three major goals of integrity in a commercial environment. To address the second goal of integrity, Clark and Wilson realized they needed a way to prevent authorized subjects from making undesirable changes. This required that transactions by authorized subjects be evaluated by another party before they were committed to the model system. This provided separation of duties where the powers of the authorized subject were limited by another subject given the power to evaluate and complete the transaction. To address internal consistency (or consistency within the model system itself), Clark and Wilson recommended a strict definition of well-formed transactions. In other words, the set of steps within any transaction would need to be carefully designed and enforced. Any deviation from that expected path would result in a failure of the transaction to ensure that the model system’s integrity was not compromised. To control all subject and object interactions, the Clark–Wilson model establishes a system of subject–program–object bindings such that the subject no longer has direct access to the object. Instead, this is done through a program with access to the object. This program arbitrates all access and ensures that every interaction between subject and object follows a defined set of rules. The program provides for subject authentication and identification and limits all access to objects under its control.
- 非MAC
- Integrity
- 外部完整性→防止外部不當修改 (Biba)
- 內部完整性→防止內部授權不當修改
- 一致性

- SoD
- 外部完整性→authentication
- 內部完整性→ 看Rule(當/不當) → 適合與否 → 可以在application去implement這個Rule
- 一致性:檢查輸入和寫入
- 防止不當的修改

- Graham-Denning
- Harrison-Ruzzo-Ullman

#### Bell–LaPadula Confidentiality Model



| SUBJECTS | OBJECT1 | OBJECT2 |
| --- | --- | --- |
| Subject A | Read only | Read/Write |
| Subject B | No access | write only (append) |

#### Three Properties of BLP

| Property Name | Bell-LaPadula |
| --- | --- |
| Simple Security | SECURITY: subject cannot access or read an object of higher security level (No Read Up) |
| Star(*) | Subject can only save or write an object at same or higher security level (No Write Down) |
| Discretionary | The model allows for an access matrix |

#### Biba integrity Model



#### Three Properties of Biba

| Property Name | Biba |
| --- | --- |
| Simple Integrity | INTEGRITY : subject cannot read or access object of lower integrity level (No Read Down) |
| Star(*) | Subject cannot write to object at higher integrity level (No Write Up) |
| Invocation | Subject cannot send service requests to or request access to object of higher integrity |

#### Knowledge Check

- Identify the focus or problem that each security model addresses:
- Bell-LaPadula C
- Biba I
- Brewer and Nash C
- Clark-Wilson I
- Graham-Denning
- Harrison, Ruzzo, Ullman

### Understand security capabilities of information systems (3.4) And Assess and mitigate the vulnerabilities of security architectures, designs, and solution elements (3.5)

#### Security Engineering

- Commonly accepted sources for engineering processes:
- 打造安全系統
- ISO/IEC/IEEE 15288 → Systems and Software Engineering
- ISO 15026 → Systems and software engineering — Systems and software assurance
- NIST SP 800-160 → System Security Engineering
- International Council on Systems Engineering (INCOSE)

#### System and Security engineering Processes



- Assurance 保證做到
- 做assurance 是另外一回事
- Assurance做有效性→

#### NIST SP800-160v1r1(2022): Engineering Trustworthy Secure Systems

- Four Process Areas: Consistent with ISO 15288
- Technical Processes
- All aspects of requirements, development, production
and operational use
- Technical Management Processes
- All project and program management, assessment, tracking, change control, direction, quality assurance
- Organizational Project-Enabling Processes
- Choice of lifecycle model; infrastructure; human resources, quality management, knowledge management
- Agreement Processes
- Acquisition, supply, contracting

#### Security Policies, Models and Architecture

- Policies
- What you want to accomplish
- Models
- Theoretical description of how it works
- Architecture
- How it will be built

#### Ring Architecture


- 硬體架構的層面來看
- 軟體架構 → kernel driver一層然後外面包一層
- 越往外圈權限越低
- 雲端業者提供機密運算→ 概念 → 安全性會有一推規則、加密

[Untitled.m4a](https://prod-files-secure.s3.us-west-2.amazonaws.com/bdf9d7ee-0df8-43d1-8257-eb7aab9df52c/27a30c0a-2af1-4314-a3dc-c66fe6e5beb8/Untitled.m4a)

---

#### To Understand the fundamental concepts of security models (3.2)

以下皆為重要

#### Security Capabilities in System and Architecture

- 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

#### Common Risks and Controls on Different Systems Architectures

- hybird-analysis.com、Eerodium、omg cable、certification.hark and shodan



- 分類當中，所存在的安全問題

#### Client-Based systems

- Characteristics
- Desktops, laptops, thin client terminals, etc. (endpoints)
- Many client endpoints
- Constantly adding, updating, removing endpoints
- Inconsistent usage and behavior patterns
- Vulnerabilities
- Physically under end user control
- Susceptible to user misuse (intentional or accidental)
- May be lost/stolen
- Monitoring may be difficult
- 100% update may be difficult
- Mitigations
- Awareness training
- Endpoint management
- HIDS

---

- Client-based systems traditionally have been the endpoints at which users accessed centrally provided information services. These endpoints may be high-performance general-purpose workstations, other desktop computers, laptops, point-of-sale devices or other personal devices. As clients, they communicate with a server (a service-providing computer system), typically via a network connection of some kind. These devices are sometimes categorized as “thick” or “thin” to reflect the complexity of applications (and supporting OS) that runs on that device so that it can perform its functions in the overall system. With their own local storage, connectivity and other capabilities, thick client devices are often referred to as client-based systems. But the line between thick and thin clients is blurred and continuously changing. Client devices, systems or both, are typically present in large quantities in most organizations. Most organizations are continually adding new client systems and decommissioning old ones.Client-side or client-based systems can be large, complex systems.


- 攻擊方看在機會不看computing分類
- 檔案 → office檔案(巨集)
- 超連結 → zero click → https://zerodium.com/

- usb → omg cable
- shodan
-
- EvilMaidAttack → 去攻擊無人看管的電腦(實體機器)
- 要先思考完攻擊，才有機會去思考防禦，不思考攻擊的防禦就是幻想
- 害怕就上patch

- Vulnerabilities
- Client-based systems have vulnerabilities inherent in their hardware, OSs and applications software, including being vulnerable to malware, misuse or accident. They are also susceptible to damage or theft, putting any data remaining in the device at risk of loss or compromise.Exploiting these vulnerabilities can enable an attack on the servers or other systems connected to them.
- Physically under end user control
- Susceptible to user misuse(intentional or accidental)
- May be lost/stolen
- Monitoring may be difficult
- Mitigations
- Almost any mix of thick or thin clients presents a general endpoint security management problem to the organization:
- Host-based anti-malware and intrusion detection and prevention software should be installed directly on the client device or as part of centrally managed solutions.
- Endpoint management systems can monitor the client-based system’s health and status, install software and data and manage software updates and patch installation. When combined with mobile device management, endpoint management can also mitigate risks due to loss or theft of the device.
- General network protection measures, such as segmentation, firewalls and intrusion detection, can also protect both the client and the network from each other.
- Awareness training
- Endpoint management
- HIDS

#### Server-Based systems

- Characteristics
- Multiple types, different purposes
- Centrally managed/controlled
- Limited access/functionality
- Likely to be in a tightly controlled network segment
- Vulnerabilities
- Operate for many years, with some using software long past support
- High data throughput and service provision rates
- Connected networks
- Physical access/connections
- Mitigations
- Physical, logical, or administrative access controls
- Redundant elements
- Configuration and change management
- Strong remote access mechanisms
- Logging and monitoring

---

- Server-based systems generally provide a specific purpose and may be specially configured or have software loaded to provide a particular function. Common types include application servers, file servers, controllers, print servers and network service servers (e.g., Domain Name Service). Typical server systems use special local area networks to interconnect processors, memory, file storage and connectivity to client systems or other services. Hybrid server systems may also incorporate a mix of on-premises or off-premises cloud services as part of their service delivery mechanisms. They are often centrally managed, controlled and maintained in most organizations and have limited access or functionality beyond their specific intended purpose.
- 如上圖 system 和實體
- Vulnerabilities
- As with client-based systems, server-based systems may be vulnerable to exploits against their hardware, OSs, applications and networks. Server systems are sometimes kept in operation for many years, with some using software that is long past its window for vendor or creator support, because there is limited operational redundancy and therefore no opportunity to take them out of service to perform updates and apply patches—even security-critical ones.
- Typical servers operate with much higher data throughput and service provision rates than even the most powerful desktop workstations. As a result, log files and other activity monitoring systems generate much more data, more quickly, all in need of analysis.Being connected to one or more networks exposes servers to sources of attacks over those networks.
- Physical access to the server system, including its interconnection fabric and network connections to endpoints and other services, can expose the system to an almost unlimited range of attacks. The entire logistics supply chain that provides service and support to an organization’s server systems may also be a source of exploitable physical, logical or administrative vulnerabilities to a determined attacker.
- Operate for many years, with some using software long past support
- High data throughput and service provision rates
- Connected networks
- Physical access/connections
- Mitigations
- For server architectures that have not migrated into cloud-hosted or virtual systems, adding redundant elements can provide a cost-effective approach to improve maintainability and service availability. Adding affordable redundancy all but eliminates the need to defer downtime for maintenance, which can dramatically reduce the lag time between receiving a security patch or update and applying it to the system.
- Physical, logical or administrative access controls can protect server systems, their networks and their support and logistics elements from many attempts to attack them.
- Physical, logical, or administrative access controls
- Redundant elements
- Configuration and change management
- Strong remote access mechanisms
- Logging and monitoring

#### Database Systems

- Characteristics
- Hosted on servers, cloud, distributed, etc.
- Inherits platform vulnerabilities
- Requires high-speed operation with high volume of transactions
- Contains large quantities of valuable information
- High-value target
- Vulnerabilities
- Aggregation
- Inference
- Data mining output
- Poor access control
- Vulnerable applications
- Mitigations
- Robust authentication/access control
- Output throttling
- De-identification
- Encryption
- (More on domain 8)

---

- Database systems are usually built around a database management system (DBMS) and the processor and storage systems that host it. They can be hosted on individual endpoints or thick clients, where they provide database services to other applications running on that client. Individual servers or server clusters can support larger database systems, providing larger data volumes, higher throughput rates, and concurrent access to a larger number of users. Most database systems now operate in cloud hosting environments, distributed computing environments and hybrids of these models. Database systems inherit any platform vulnerabilities and add database-specific vulnerabilities. They typically contain large quantities of valuable information and must support high throughput rates for transaction processing and data retrieval. As a result, these systems tend to be high-value targets for any attacker.
- Vulnerabilities
- Vulnerabilities specific to database systems include:
- Malformed inputs
- Denial of service
- Avoiding or side-stepping access controls
- aggregation 資訊拼圖
- inference 推論，用猜的
- Data mining output
- Poor access control
- Vulnerable application
- Mitigations
- Robust authentication/ access control
- Output throttling
- De-identification
- Encryption
- (Domain 8)

#### Virtualized Systems

- Characteristics
- Hardware, network functions abstracted by software
- Many strategies for control, use, update, management of VMs
- Usages: Cloud, sandbox, development, security test, other uses
- Vulnerabilities
- Inherit host hardware, hypervisor and OS vulnerabilities
- Poor access control
- VM escape
- Poor management
- VM sprawl
- Mitigations
- Configuration/change management
- Proper IAM
- Management platform

---

- Hardware virtualization has its roots in the mainframe world of the 1970s, where IBM’s System 360 architecture provided virtual partitions to allow different OSs to coexist on the same processing platform. This virtual partitioning significantly reduced the cost of developing and testing different OSs by not requiring separate hardware for each environment. Since then, this technology has become widely available on many computing platforms.
- Application virtualization abstracted the user interface from the processing activities. This allowed systems with limited computing resources to run complex applications. These thin clients needed only to establish connectivity with the application server to leverage its processing power to perform the actual work. For many organizations, this simplified application installation and maintenance. It also provided a separation between the application host and the user, limiting the effect of many malware attacks on the client, as the application (and data) was residing elsewhere.
- Virtualization of entire hardware platforms began to move into mainstream environments in the early 2000s. Extensive server farms were virtualized, often with significant savings in power consumption and data center space costs, not to mention reducing the number of computers needed to run an organization’s set of business processes as previously unused resources were pooled and allocated as needed. This trend directly influenced the development of cloud technology.
- Virtual machine (VM) images are the sets of files containing the in-memory image of the entire execution environment—the OS, the application, configuration details and data files. They may contain multiple virtual disks and virtual network definitions. As such, they can be copied and relocated easily. In most virtualization environments, a simple user command can cause a VM image to be loaded and start executing; a script file can cause any number of VMs to be spawned (copied as instances and loaded for execution) in seconds.
- 容器確切在虛擬化技術找到一個大家可以接受的特點

- Vulnerabilities
- The vulnerabilities inherent to virtualized systems include:
- Image management (“VM Sprawl”). Without effective control mechanisms and policies, VM images can be loaded and left running. Copies of them can be moved to other areas of the system or exfiltrated.
- VM escape. Improperly configured authentication environments open the possibility that a malicious actor may take advantage of credentials on a VM to attack the larger environment.
- Underlying hardware weaknesses. Poor programming practices2 and sophisticated hardware attacks3 against the hypervisor can compromise all workloads.
- Knowledge gap. Using virtualization securely and safely often requires expert levels of software and network engineering knowledge. Many cloud systems breaches, for example, are the result of naive users failing to make the most effective use of their cloud providers’ built-in VM security capabilities.
- 偏向漏洞面
- Inherit host hardware, hypervisor and OS vulnerabilities
- Poor access control
- VM escape
- Poor management
- VM sprawl
- Mitigations
- Mitigations for virtualized systems include:
- Change management. Ensuring that license, patch and vulnerability management practices are applied consistently to VMs and the virtual environment is essential.
- IAM. Proper implementation of IAM to protect the hypervisor from the production workloads using granular role-based and attribute-based access controls and other privilege management tools is essential.
- Configuration/change management
- Proper IAM
- Mangement platform

#### Cloud-Based Systems

- NIST Essential Characteristics
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service

- ISO 22123-1:2023 ~~17788~~ addition
- Multitenancy

---

- Another three-plane slice of a cloud data center uses compute, storage and management. This also physically and logically separates the computing resources from the storage and networking resources, connecting these elements through a management infrastructure that synchronizes and orchestrates the changes necessary to support the applications. Generally, network services, both virtual and real, tend to be defined in the compute plane but use services (just like compute does) from the other two planes.
- The separation of resources is not visible to the applications, as their requests for service are handled through multiple layers of abstraction through many different APIs. Let’s look at these resources separately.
- Compute. Underlying the cloud is a set of processors and physical memory. These resources are directly controlled by the hypervisor, which is responsible for isolation of the various VMs, processes and computing workloads. Type I hypervisors are part of the OS of computing resources. Type II hypervisors run as an application inside an independent OS. The Type I hypervisor has a significant performance advantage over the Type II approach. However, the Type II hypervisor is convenient for sandboxing and development activities. In this model, a containerization layer may also be used to reduce the resources needed for VMs when running applications.
- Storage. The compute resources require a variety of storage types, all of which exist inside some configuration of physical storage devices. This may include different media types, including magnetic and solid-state storage. Storage APIs may also support other physical storage devices (worm drives, magnetic tapes and others) to meet specific storage needs. The media is accessed through a virtual storage controller, responsible for managing the physical and logical arrangement of the information on the storage devices. Applications and services access storage through APIs that present the virtualized environment to VMs and services as logical drives, objects or other storage types. Reconfiguration and relocation of information and data replication is transparent to the applications, simplifying the systems administration work needed to support the storage environment.
- Network. The typical cloud environment will interconnect physical network devices (such as routers, switches, firewalls) so that the proper movement of traffic occurs, while maintaining sufficient bandwidth to support the applications and workloads. The cloud environment partitions the network space to isolate customers, who may (depending on their needs) apply additional logical segregation to the networking environment. As with storage, the access to this virtualized resource is through APIs that reconfigure the environment to meet load and redundancy requirements.
- Management. This plane plays a critical role in synchronizing the requests for different services between the various components. For example, the management plane will take a request from the hypervisor requesting additional storage for a VM and mediate the request with the storage environment to ensure it is properly provisioned. From a security perspective, the management plane must be isolated from direct access to the customer environment.
- NIST Essential Characteristics
- On-demand self-service
- A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
- Broad network access
- Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops and workstations).
- Resource pooling
- he provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically assigned and reassigned according to consumer demand. Examples of resources include storage, processing, memory and network bandwidth.
- Rapid elasticity
- Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.
- Measured service(服務計量)
- Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth and active user accounts).
- ISO 17888 addition
- Multi-tenancy(多用戶環境)
- A feature where physical or virtual resources are allocated and controlled so that processing and data for different end-user organizations (tenants) are isolated from and inaccessible to one another.

#### Service Models

- NIST Defined Service
- Software as a Service (SaaS)
- Platform as a Service (PaaS)
- Infrastructure as a Service (IaaS)

---

- SaaS:
- The consumer uses the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email) or a program interface. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, OSs, storage or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
- 現成應用程式
- PaaS:
- The consumer deploys onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, OSs or storage but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
- 軟體API
- IaaS:
- The consumer can use the provider’s capabilities to provision processing, storage, networks and other fundamental computing resources so that the consumer can deploy and run arbitrary software, which can include OSs and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over OSs, storage and deployed applications and possibly limited control of select networking components (e.g., host firewalls)
- 傳統虛擬機環境
- NaaS:
- Network as a Service. ISO/IEC 17789 adds Network as a Service (NaaS) as an additional service category. NaaS provides its consumers with virtualized transport, connectivity and network management capabilities.
- Communications as a Service (CaaS)
- Compute as a Service (CompaaS)
- Data Storage as a Service (DSaaS)

#### Deployment Models

- Private
- Exclusive use by a single organization
- On or off premises
- Public
- Open use by general public (free accounts)
- Contracted services (CSP)
- Community
- Provisioned for exclusive use by a community of users
- Hybrid
- Combination of two or more deployment models

---

- Private cloud
- In this model, the cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed and operated by the organization, a third party or some combination of them, and it may exist on-or off-premises.
- Public cloud
- The public cloud infrastructure is provisioned for open use by the public. It may be owned, managed and operated by a business, academic or government organization, singly or in combination. It exists on the premises of the cloud provider.
- Community cloud
- A community cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations with shared concerns (e.g., mission, security requirements, policy, compliance considerations). It may be owned, managed and operated by one or more of the organizations in the community, a third party or some combination of them, and it may exist on- or off-premises.
- Hybrid
- The hybrid cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). As more organizations are leveraging SaaS, PaaS and IaaS, it is important to be aware of the limited ability they have to define specific security controls and functions.
- Multi-cloud

#### Cloud Vulnerabilities and Mitigations

- Vulnerabilities
- Inherently exposed to external communication/access
- Misconfiguration a major risk
- May exist for long periods (risk of being outdated)
- Gaps between CSP and data owner security controls
- Mitigations
- Reputable cloud service providers
- Well-defined sharing security responsibilities
- Well-managed identity and access
- Robust configuration control/change control
- File and communication encryption
- Well-trained system administrators

---

- Vulnerabilities
- Cloud-based systems are subject to many vulnerabilities, three of which are worth necessary attention:
- Exposure to external communication and access. By their nature, cloud systems tend to be more exposed to external communications.
- inherently exposed to external communication/access
- Misconfiguration a major risk
- Cloud providers typically have well-managed infrastructures that can be highly secure if configured properly. Many user organizations, however, lack the knowledge and experience to properly configure and manage their use of the cloud service or hosted components in a way that prevents security compromises of their data or systems. Users often mistakenly assume that their CSP is responsible for all security, but users have responsibility for securing their own storage and processing capabilities.
- May exist for long periods (risk of being outdated)
- Gaps between CSP and data owner security controls
- Becoming outdated. Services ported to a cloud environment may be there for months if not years of continuous use. The service-level agreement between the CSP and consumer organization should clearly identify what elements the CSP maintains, with all others being the consumer’s responsibility. However, some consumer organizations may assume that their CSP will keep everything maintained, updated and patched.
- Mitigations
- As with any third-party service, all security mitigations have to be negotiated and implemented within the terms of the contract between the CSP and the consumer organization.
- Reputable cloud service provides
- Well-defined sharing security responsibilities
- Robust configuration control/change control
- File and communication encryption
- Well-trained system administrators

#### Edge and Fog computing System

- Characteristics
- Different definitions
- Edge computing
- Encompassing the end devices and their users, provide local computing capability
- Peripheral layer
- Fog computing
- Multilayer architecture
- Performing intelligent computing and transmission services
- Accelerate storage, control and data-processing
- Vulnerabilities
- Network compromise
- Increased attack surface
- Mitigations
- Increase network monitoring and incident response
- Strengthen inventory and accountability practices

---


- 差別在距離(distance)，影響反應時間，拉回雲端太遠，也沒必要
- HCI:把整個機房塞到你機器裡面
- Characteristics
- So far, we have looked at cloud computing largely from the perspective of the cloud data center and its service models. For cloud computing to provide virtualized resources at a significantly reduced cost, the information being processed must move to the cloud. This imposes high latency costs and may present privacy and other confidentiality concerns. Figure 3.6 shows what happens at the edge of the cloud. Fog computing places a layer of computing resources closer to the input sources, thus providing dedicated application hosting and device management services. This can optimize the movement of information into the cloud.
- Edge computing also encompasses endpoint devices, often embedded systems, as part of the edge. Initially, edge computing devices were at fixed locations, but with the advent of broadband network access through wireless technology, many mobile devices are becoming part of edge computing systems.
- Edge computing and “fog computing” address different levels of information processing. The distinction between the two environments is only now being formally addressed by various standards bodies. For example, NIST Special Publication 500-325 characterizes the differences this way:
- Fog computing is often erroneously confused with edge computing, but there are key differences between the two concepts. Fog computing runs applications in a multi-layer architecture that decouples and meshes the hardware and software functions, allowing for dynamic reconfigurations for different applications while performing intelligent computing and transmission services. Edge computing runs specific applications in a fixed logic location and provides a direct transmission service. Fog computing is hierarchical, where edge computing tends to be limited to a small number of peripheral devices. Moreover, in addition to computation, and networking, fog computing also addresses storage, control and data-processing acceleration.
- Vulnerabilities
- Network compromise
- increased attack surface
- 主要範圍變大
- Mitigations
- Increase network monitoring and incident response
- Strengthen inventory and accountability practices

#### Smart Home


#### Smart City


- ITS ：智慧運輸系統

#### Software Design Architecture


---

- SPOF : *single point of failure*
- 各個service如何做串接，利用API Gateway

#### Microservice

- Characteristics
- "Cloudy" service-oriented architecture (SOA)
- Leverages object-oriented programming models
- Minimum functionality
- Loose coupling simplifies legacy integration
- Services run independent of underlying resources (scaling)
- Deployed as containers or serverless/FaaS
- Vulnerabilities
- Vulnerable software
- IAM configuration challenges
- Latency due to poorly structured environment
- Protocol weaknesses, e.g. HTTP DoS
- Mitigations
- SSDLC
- DevSecOps
- Proper authorization, e.g. OAuth 2.0
- Rate limiting through APl gateways

---

- Characteristics
- As an implementation of service-oriented architecture (SOA) for cloud systems, microservices use lightweight protocols to provide a highly isolated messaging vehicle to pass information between applications. Converting an application to a microservices architecture involves breaking up larger programs into objects, which can be managed by the system as separate execution threads. The refactored application thus performs the same complex tasks while providing greater resilience. Developing a service to “do one thing and do it well” is a core tenet of the microservices approach.
- This modularization of the code base has several advantages. Maintenance is simplified, as a single service has a more limited scope to maintain than a monolithic program that accomplishes a more extensive set of related tasks. Converting or refactoring large, complex batch processing into real-time processing can be done without wholesale redesign and recoding of those applications, if they can easily be converted to use microservices instead. Microservice architectures can quickly scale up or down to meet demand due to their individual microservices running as independent processing threads. Dynamic scaling and load balancing can be much more difficult to achieve with legacy (non-microservice) systems and architectures.
- Loose coupling → Decoupling
- “Cloudy” Service-oriented architecture (SOA)
- Leverages object-oriented programming models
- Minimum functionally
- Loose coupling → decoupling simplifies legacy integration
- Services run independent of underlying resources (scaling) serverless/Faas
- Vulnerabilities
- Authorization. Improperly developed microservices will often be run at high privilege for the convenience of the service. If the microservice is compromised, the attacker could leverage the service for other attacks.
- Quality of service. Poorly structured microservices consume more resources to support the microservice than legacy applications. For example, spawning a VM to deploy a short-lived microservice requires the loading of the entire VM, whether the capabilities are needed or not.
- Denial of service. As the microservices rely on lightweight protocols (i.e., REST) to communicate, any weakness in the protocol itself opens the service to compromise.
- Vulnerable software
- IAM configuration challenges
- Latency due to poorly structured environment
- Protocol weaknesses, e.g. HTTP DoS
- Mitigations
- Using authentication and authorization services. Implementing efficient IAM protocols such as OAuth 2.0 or SAML-based services and enforcing least privilege against service accounts.
- Where possible, implementing microservices in containers or within serverless environments. This can reduce the resource impact of the microservice and improve performance.
- Leveraging API gateways to protect microservices from inappropriate access. This provides a mechanism to direct service requests appropriately, mediate authentication and authorization between the requester and the service, and to standardize the implementation of APIs across the infrastructure.
- SSDLC
- DevSecOps
- Proper authorization, e.g. OAuth2
- Rate limiting through API gateways

#### Containerization

- Characteristics
- Shared OS services
- Isolated applications
- Reduce size of VMs
- Reduce cost of operation
- Rapid adoption
- Containers are portable
- Multiple technologies
- Vulnerabilities
- Insecure base images
- Excessive privileges
- Container sprawl, escape
- Mitigations
- Image management
- Limit containers privileges, resources
- Micro-segmentation, firewalls
- Container management

---

- Characteristics
- Containerization provides a layer of shared OS services to reduce the size and complexity of individual VM in a cloud environment. This approach reduces the resource demands, shortens the amount of time needed to start a process and increases the standardization of OSs.
- Several different open-source technologies exist, including Docker and Kubernetes, and vendors also offer proprietary approaches. This technology has seen rapid adoption due to the relative portability of containers across clouds and the reduction in costs associated with reducing the size of the OS.
- 無作業系統的虛機
- Vulnerabilities
- Insecure base images,If the base image used to build the container is not properly secured, the container will be insecure.
- Containers running with excessive privileges (privileged flag set).
- Excessive privileges
- Unrestricted communication between containers.
- Rogue or malicious processes.
- Improper isolation from the host.
- Container sprawl, escape
- Mitigations
- Image management. Image sprawl makes managing master images difficult. Limiting the number and configuration of images allows for simpler, more consistent sets of image controls to be used.
- Immutable infrastructure. Manage the infrastructure as if it cannot be changed during execution. Specifically, one should never patch or perform other maintenance actions on a running instance. A change to a running instance will not be reflected back into the base image used to build that instance. Instead, the new system should be regenerated from a known master image, configured with automated tools through scripting processes and promoted into production through the organization’s deployment pipeline.
- Granular security. Limit the privileges for each container. If additional privilege is necessary for a process, invoke it as needed.
Microsegmentation and firewalls. Limiting communication between containers will restrict the inappropriate movement of information, including data leaks and malware.
- Proper configuration. Making effective use of containerization requires the same level of specialized knowledge as firewalls, IAM and database management. Proper configuration of the environment can be done by only people trained to do so, who know how to apply basic security concepts to these complex environments. This is particularly difficult as the containerization platforms themselves are constantly evolving, and as a result, today’s secure configuration may not be appropriate tomorrow.
- Limit containers privileges resource
- Micro-segmentation, firewalls
- Container management

#### Serverless Architecture

- Characteristics
- Serverless architectures extend the responsibilities of the CSP to completely abstract the underlying physical and logical infrastructure from the development and deployment of the application. Often referred to as Function as a Service (FaaS), serverless computing makes the CSP responsible for the infrastructure’s elasticity to support the application, reallocating resources to meet increasing or diminishing workloads.
- In a serverless architecture, the services are accessed as functions, responding to events from other functions or outside requests. API calls can provide direct inputs, but more commonly, an API gateway manages these. Other sources of events might include a file update, log entry or a database transaction.
- Vulnerabilities

This architecture is a relative newcomer to the cloud environment. Many of the attack patterns related to this architecture are consistent with attacks against other architectural types.8 This list describes only a few of the architecture-specific vulnerabilities.

- Malicious injection into the function. Improperly formed inputs into the function may compromise the function, causing DoS or information disclosures.
- Insecure configuration. Vendors have unintentionally made secure configuration of their cloud services more complex by adding configuration options in an attempt to differentiate their product in the marketplace.
- Cross-execution data persistency. A serverless function may rely on stored data in several forms to reduce latency and more efficiently share information. If the information is not properly protected at rest and not appropriately purged after use, it may be subject to disclosure.
- Mitigations
- Train staff on the proper configuration of the vendor environment.
- Employ secure coding practices, including robust testing using static, dynamic and interactive code testing methodologies.

#### High-Performance Computing systems

- Characteristics
- Highly complex computational science and mathematical applications
- Significantly more computational resources
- Maximize the productive(customer) use of resources
- Supercomputers, computer clusters, cloud computing
- Vulnerabilities
- Network latency
- Unauthorized workloads
- Same traditional security concerns
- Mitigations
- Proper design
- Appropriate monitoring and logging


---

- Characteristics
- Solving certain types of problems requires significantly more computational resources than are generally available to the public. Modeling the effects of nuclear explosions, evaluating the impacts of climate change on estuaries and simulating earthquakes are examples of use cases that benefit from massive numbers of processors working simultaneously.
- Government agencies with large budgets have been the traditional users of high-performance computing (HPC) systems. More recently, a variety of commercial ventures have made HPC resources available, often in conjunction with cloud services. They do this as a business goal by maximizing the productive (customer) use of computational resources while minimizing its use on nonessential activities. This may require compromising traditional security controls to achieve higher performance. Further, while many of the security risks associated with HPC environments are similar to the problems faced generally, unique challenges exist in the areas of integrity and availability.
- 超級電腦
- AI
- Vulnerabilities
- Latency constraints. Given the speed at which the parallel processes must communicate, traditional tools such as IDS/IPS or firewalls would impose unacceptable latency costs on the processes being performed.
- Improper workloads. If compromised, the HPC’s time could be consumed by unauthorized workloads, constraining resources for legitimate tasks.
- Mitigations
- Proper architectural design. Architecting secure computing enclaves and positioning detection tools around the environment’s perimeter may compensate for reducing security controls within the HPC environment itself.
- Appropriate monitoring and logging practices. Logging imposes a computational cost but is invaluable when determining accountability. Proper design of logging environments and regular log reviews remain best practices regardless of the type of computer system.

[Untitled.m4a](https://prod-files-secure.s3.us-west-2.amazonaws.com/bdf9d7ee-0df8-43d1-8257-eb7aab9df52c/ab16d4a1-a066-4b8a-b43c-614f83691200/Untitled.m4a)

---

以下偏硬體架構

#### Industrial Control systems

- Combination of hardware and software used to control industrial processes such as manufacturing, product handling, production, and distribution.

what if temperature is tamp and heating coil keeps heating?


---

- 非樹莓派

- 越往上走越需要安全，越往下走越不需要安全

#### Industrial Control Systems(ICS)

- Characteristics
- Direct control and monitoring of physical systems
- Control and monitoring at many levels
- On-device; on-site custom interface;
LAN; internet
- Vulnerabilities
- Unsecure locations
- Proprietary designs, software, interfaces
- Unsecure communications
- Updates can be difficult
- Attacks can cause injury, property damage
- Mitigations
- Isolation, segmentation
- Configuration control
- Secure protocols
- IEC 62443

---

- 左邊通常不重要
- controller 通常可以下指令，指令來自於SCADA


- Characteristics
- Industrial systems and critical infrastructures are often monitored and controlled by simple computers called industrial control systems (ICS). Since most ICS are used to control industrial machinery, safety requirements are often more critical than security ones; that said, many of the strategies for safe systems design and operation result in overall security improvements.
- ICSs are based on standard embedded systems platforms, and they often use commercial off-the-shelf software. ICSs are used to control industrial processes such as manufacturing, product handling, production and distribution.
- They typically have components that execute software on embedded, limited function hardware. They may contain interfaces between logical (computer) space and the physical world. These may include sensors, motors, actuators, valves, gauges and the various analog to digital converters necessary to bring the physical world closer to the digital world.
- Viewed from the top of the control architecture down, there are three general components that compose an ICS:
- Supervisory control and data acquisition (SCADA) systems are assemblies of interconnected equipment used to monitor and control physical equipment in industrial environments. They are widely used to automate geographically distributed processes such as electrical power generation, transmission and distribution, oil and gas refining and pipeline management, water treatment and distribution, chemical production and processing, rail systems and other mass transit. SCADA systems are event-driven, gathering information from the attached distributed control systems, programmable logic controllers, sensors and other devices.
- Distributed control systems (DCSs) are typically confined to a geographic area or manufacturing facility, a DCS may encompass large numbers of semi-autonomous controllers. DCSs share many similarities with SCADA systems and may operate with a mix of proprietary and industry-standard protocols. They are process-oriented, providing control and instruction to the attached programmable logic controllers, sensors and related devices to manage a particular process. They operate autonomously, reporting status and events to a larger SCADA if logging and alerting is necessary.
- Programmable logic controllers (PLCs) are ruggedized industrial controllers that use specialized hardware, firmware and software to provide real-time control and monitoring of their attached equipment. The inputs may come from a sensor or another PLC, and the outputs may drive an actuator for a valve or control a relay. A PLC may be a stand-alone system or included as components in SCADA or DCS infrastructure.
- IIOT ⇒ IT + OT;把這些生產控制系統的資訊帶到電腦環境
- teensy
- stuxnet
- Vulnerabilities
- Unsecure locations
- Proprietary designs, software, interfaces
- Unsecure communications
- Updates can be difficult
- Attacks can cause injury, property damage
- Mitigations
- Isolation, segmentation
- Configuration control
- Secure protocols
- IEC62443

#### Internet of Things (IoT) Reference Architecture

#### Internet of Things (IoT)

- Characteristics(devices)
- Consumer, industrial, business, agricultural, medical...
- Small, embedded form factor
- Limited functionality OS
- Physical control & monitoring
- Pervasive, often connected to general purpose networks
- Functions/accessibility may be unclear to owner/user
- Convergence of loT devices, networking and applications
- Vulnerabilities
- Poor code management, update
- Minimal security built-in
- Cryptographically weak
- Left unattended
- Default credentials
- Mitigations
- Endpoint management
- Segmentation, isolation
- Secure update
- Physical hardening

---

- Characteristics
- The increasing miniaturization of embedded systems and the ubiquity of wireless networks to provide connectivity to previously discrete infrastructures have created tremendous opportunities for monitoring and interacting with the physical environment. Refrigerators, road condition monitors, smartwatches and a myriad of other types can now communicate and provide inputs to other systems for decision-making.
- The complexity and capability of Internet of Things (IoT) devices start with simple status monitoring tools using relatively small OSs and input sensors and go on to include highly complex, calibrated devices with safety-of-life implications. They may be built using general-purpose OSs that support a rich, complex application suite. They may also include standard communications protocols and employ secure cryptographic algorithms to protect their communications. As a result, this new class of devices, no longer isolated on their own separate networks, present an expanded attack surface relative to the legacy embedded systems.
- Vulnerabilities
- DoS. While many of the vulnerabilities applicable to ICSs and embedded systems can be found in IoT environments, the increased reliance on wireless communications protocols presents additional weaknesses. Where the target IoT device uses standard communications protocols, the weakness of those protocols comes into play. The use of proprietary or nonstandard protocols brings with it the potentially exploitable vulnerabilities within those implementations. IoT communications may also transit multiple infrastructures as they establish connections and share data. As a result, DoS attacks can significantly degrade the quality of service between the devices. Latency costs imposed by retransmission reconnection or encryption must be considered in system design.
- Device security. The remote location of the IoT devices may open them to physical attack, including theft. This exposes the IoT system to data remanence exploitation or reverse engineering attacks; the stolen device may also be repurposed to be part of a subsequent attack. Further, if the device is monitoring a process or environment (e.g., a wireless camera or a temperature sensor), manipulating the environment may be a productive avenue to compromise the device.
- Cryptographic security. Not all IoT devices have the computational horsepower to perform complex cryptographic operations on communications and stored data.
- Mitigations
- Endpoint management
- Segmentation ,isolation
- Secure update
- Physical hardening

#### Embedded Systems

- Characteristics
- Embedded systems are microcomputer technologies directly incorporated into mechanical, electrical, hydraulic or other kinds of devices. These microcontrollers replace or augment control systems such as mechanical thermostats, regulators or load balancing mechanisms. They can provide a broader range of control functions, improve the overall system’s reliability and performance, gather monitoring data and upload it to off-board systems for analysis, trending and other uses. This embedding of technology can be found in automobiles, airplanes, consumer appliances, medical devices and security systems. With simple OSs and relatively low power requirements, embedded systems are often less expensive, easier to maintain and more precise than their analog predecessors.
- Nevertheless, embedded systems present a substantial operational risk. If they fail to perform their function for any reason, the system they support may become inoperable. In many environments, this level of risk is unacceptable. Applications with safety of life requirements quite often require some level of control redundancy to achieve the operational reliability necessary to achieve safety requirements.
- In many embedded systems, the code base is maintained in read-only memory and is not updatable. In other cases, the firmware can be updated, either remotely or locally, depending on the system’s communications capabilities. Regardless, maintaining the code of embedded systems presents unique challenges in risk assessment, code validation, distribution across the installed base of systems and deployment.
- Security professionals should be aware that the dividing line between ICSs and embedded systems is somewhat blurred. A motor-driven valve may have an analog electrical control signal or a digital one; in either case, its onboard control circuitry may or may not contain a digital microcontroller. Many ICSs contain embedded systems as part of both their control processes and the systems that the ICS controls and monitors. The ICS itself may be embedded into a device.
- Vulnerabilities
- Programming errors. Poor coding practices are a primary cause of weaknesses in embedded systems documented in the National Vulnerability Database. Failed input validation, improper buffer management and poor memory management practices have been well documented. These challenges may occur for many reasons, including the limitations of the embedded OS or poor coding practices within the application.
- Web-based vulnerability. Many embedded devices have a web-based management interface through which they can be configured and updated. However, due to poor vulnerability management practices and the limitations of the embedded environment, the embedded web applications on those devices are often left exposed to known weaknesses.
- Weak access control or authentication. Many devices use weak default passwords, often with hard-coded credentials that give backdoor access to the device, ostensibly to simplify the vendor’s access for support.
- Poor cryptography practices. Poor cryptographic algorithms and flawed implantation can often be exploited to compromise the device. Algorithms used to support access controls are particularly weak, often relying on legacy methods of authentication.
- Reverse engineering. Often, the firmware can be analyzed through special techniques, exposing the intellectual property of the software or allowing the attacker to identify other weaknesses in the source code.
- Malware. The Stuxnet virus highlighted the capabilities of sophisticated attackers in targeting and compromising embedded systems. Because these systems are often used to support complex industrial processes requiring precise control, they are lucrative targets when an attacker seeks to disrupt the business process.
- Eavesdropping. Monitoring of communication streams by attackers is a well-established form of compromise. Whether the attacker seeks to exploit the information by observing the communications flow or intends to execute replay attacks against the target, the effects can be devastating. Coupled with weak or non-existent cryptographic protections over communications, an attacker can manipulate the transactions in the environment, often without detection.
- Mitigations
- Risk assessment. Integrating embedded systems into the organization’s risk assessment framework is essential. Without comprehensive inventories of the systems in place and evaluating the level of risk that the system poses to the environment, it is virtually impossible to develop comprehensive plans to protect the environment.
- Patching and updating. Where possible (given the limitations of vendor support and the hardware itself), maintaining the embedded systems’ code base should be performed consistent with the organizations’ vulnerability management standards.
- Secure coding techniques. Use of proper cryptographic algorithms, static and dynamic code analysis and obfuscation techniques in the deployment of code may reduce the risk of some of the common forms of compromise noted above.
- Implementing third-party risk management practices. Embedded systems are often part of vendor products integrated into an organization’s environment. Consequently, evaluating the third parties’ development and software management practices must inform the organization’s risk assessment processes to ensure a proper assessment of operational risk.

#### 3.4 and 3.5 Knowledge
1. Where within a database system does the application operate?
A. Ring 0
B. Ring
C. Ring 2
D. Ring 3

2. A junior member of staff has been reading about the Ring model and wants to know where in the model a type 1 hypervisor would operate. What do you tell her?
A. Within the OS kernel
B. Within the device drivers
C. Within the system utilities
D. Within the applications

3. The generic operating system provides separation of duties by effectively creating two modes of operation known as user mode and kernel mode. Where in the ring model would user mode operate?
A. Rings 0, 1, and 2
B. Rings 1, 2, and 3
C. Ring 2 only

D. Ring 3 only

4. Your organization has been infected with a user-mode rootkit. Where is it running?
A. Ring 0
B. Ring 1
C. Ring 2
D. Ring 3

5. The security kernel monitors the overall operations of the OS. If a failure occurs within the OS what steps are taken by the security kernel?
A. It physically shuts down the system.
B. It sends a restart signal and the system reboots.
C. It places the OS into a high-security state, often causing a "Blue Screen," and dumps the contents its registers into a file.
D. None. The security kernel takes no further as it fails with the OS.