IoT Security Guideline 2 - Service Ecosystem
The Security Model
- A Web Service Tier
- An Application Server Tier
- A Database Tier
- An Authentication Tier
- A Network Tier
Even if there is only one server in each tier, it is more architecturally effective to separate each logical concept into its own tier. This also helps isolate one layer of technology from other layers in the event of a compromise, or if the system needs to scale up to serve more requests.
This proxy server is just a descriptor representing the actual security technology that will be employed within the tier. Regardless of whether the actual control is a hardware firewall, software firewall, Security Groups, Access Control Lists (ACL), or another technology, there will be a component that mandates ingress and egress controls on behalf of the tier.
For publicly accessible components, like the Service Front-End Tier, the only augmentation the model needs is an additional security component for:
- Distributed Denial of Service (DDoS) protection
- Load balancing
- Redundancy
- Optional Web Application Firewall (WAF) capability
plus:
- Logging to a centralized log service
- Administrative Authentication and Authorization
- Communications security enforcement
- Data backup, restoration, and duplication
- Separation of application duties
- System Monitoring and Integrity
Networking Infrastructure Attacks
The most common form of attack in this model is the Man-In-The-Middle (MITM) attack. This attack presumes that there is either no peer authentication, one-sided peer-authentication, or broken mutual authentication on the communications channel. An adversary』s goal is to impersonate one side of the conversation to force the peer to perform actions on the adversary』s behalf. This attack can be mitigated by enforcing mutual authentication, which requires a well-defined Organizational Root of Trust, a Trusted Computing Base (TCB), and a communications model.
Other attacks are, for example, attacks against Forward Secrecy, encryption communications analysis, and side-channel attacks. These must be mitigated using proper cryptography protocols, algorithms, and standards.
Attacks against core internet infrastructure typically involve Border Gateway Protocol (BGP) hijacking, attacking a core router, or abusing the Domain Name Service (DNS) infrastructure.Regardless of which type of attack is utilized, this model is easy to mitigate using mutual authentication, forward secrecy, and appropriate cryptographic protocols and algorithms.
Cloud or Container Infrastructure Attacks For example, if an adversary is able to compromise a Cloud service network, they may have access to hosts running guest Virtual Machine (VM) systems. This would allow the adversary to inspect and modify running VM systems. The adversary may have specific targets in mind, or may have gotten lucky and compromised a Cloud service provider just for the access to many different types of systems with valuable data.
Another Cloud or Container infrastructure attack presumes that the adversary has control over a VM on the same physical server as the target VM. The adversary may then use several methodologies to compromise other VMs on a physical server. They could:
- Use a vulnerability in the VM infrastructure to break out of a Guest into a Host system
- Use a side-channel attack to infer secret keys from another Guest VM
- Consume excessive resources on the physical server to force a target VM to migrate to a physical server that the attacker has more control over
One way to reduce this risk is to implement a Container based architecture that limits each container to one specific user and a unique cryptographic identity.
However, it is notable that this type of compromise is largely undetectable by the guest VM, or an application running on top of it. Thus, metrics may be gathered that reveal anomalies in the behaviour of a particular Cloud VM or Container, but it may be extremely difficult toidentify whether or not a compromise actually occurred. This is because any adversary with sufficient privilege at the host layer of the VM infrastructure would be able to manipulate the guest to make it difficult for it to detect manipulation.
But, escalation attacks from guests to hosts in a VM, container, or hypervisor environment are difficult to find and even more difficult to exploit. This makes it much less likely that a vulnerability will result in exploitation of a mass amount of guests, or a specific target.
Therefore, while this is a significant position of privilege for attackers, the likelihood of a successful attack is low as the difficulty, cost, and opportunity make exploitation mostly impractical.
Application Service Attacks(greatest risk)
The application presents the largest layer of complexity in any product or service, and always contains the potential for an adversary to increase their privilege through multiple tiers of technology.
privacy Legal liability can be diminished through contracts and insurance clauses, however, losing customers can occur due to a third party』s failure. Rather than risking such a loss of business, an organization should evaluate third party engineering teams to determine what level of security they apply to their infrastructure, applications, and APIs. If the level of security is not sufficient, it is recommended to look for alternative partners.
Malicious Objects Since malware comes in many forms, ranging from polymorphous file types, to Adobe Flash, Java, and multimedia exploits, there is no single uniform way to guarantee the end-user』s safety. A simple solution would be for the engineering team to enforce a policy on what technologies are used over their channels, and how their users will be impacted. Monitoring subsystems can be put into place, as well as sandboxes, to ensure that any object rendered on a client system is less subject to abuse.
Frequently Asked Security Questions
- How do we Combat Cloning?
- Define an Organizational Root of Trust
- Use Network Authentication Services
- Force Authentication Through the Service Ecosystem
- Define Application Layer Authentication and Authorization
- How Are Users Authenticated via the Endpoint?
- Implement a Service Trusted Computing Base
- Organizational Root of Trust
- Define a Clear Authorization Model
- Use Network Authentication Services
- Force Authentication Through the Service Ecosystem
- Enforce Strong Password Policy
- Define Application Layer Authentication and Authorization
- How can the Service Identify Anomalous Endpoint Behaviour?
- Define a Security Front-End for Public Systems
- Define a Systems Logging and Monitoring Model
- Define a Communications Model
- Use Network Authentication Services
- Implement Input Validation
- Implement Output Filtering
- Use Partner-Enhanced Monitoring Services
- Use a Private APN for Wireless Connectivity
- Define a False Negative/Positive Assessment Model
- How can the Service Restrict an Abnormally Behaving Endpoint?
Once an endpoint is identified as behaving abnormally, the service should make decisions as to what resources should be limited or restricted. This question is relevant to every layer of the service infrastructure.
- Define an Organizational Root of Trust
- Define a Security Front-End for Public Systems
- Define an Incident Response Model
- Define a Recovery Model
- Define a Sunsetting Model
- Define a Communications Model
- Define a Breach Policy for Abused Data
- Force Authentication Through the Service Ecosystem Use a * Private APN for Wireless Connectivity
- Define a False Negative/Positive Assessment Model
- How Can I Determine Whether a Server or Service Has Been Hacked?
- Define an Administration Model
- Define a Systems Logging and Monitoring Model
- Define an Incident Response Model
- Implement Input Validation
- Implement Output Filtering
- What Can I Do Once A Server Has Been Hacked?
The complexity in doing so often arises from determining what resources, information, and accounts have been put at risk.
- Define an Incident Response Model
- Define a Recovery Model
- Define a Sunsetting Model
- Define a Set of Security Classifications
- Define Classifications for Sets of Data Types
How Can the Service Architecture Limit the Impact of a Compromise?
- Implement a Service Trusted Computing Base Define a Bootstrap Method
- Define a Security Front-End for Public Systems
- Define a Persistent Storage Model
- Define an Administration Model
- Define a Sunsetting Model
- Define a Clear Authorization Model
- Provision Servers Where Possible
- Define an Application Execution Environment
- Virtual Machine Compromises
How Can The Service Architecture Reduce Data Loss During a Compromise?
unique tokens should be provisioned to services that then act on behalf of a specific user within the storage infrastructure. This way, an attacker with access to the data storage environment may be able to connect to the service, but should not be able to interact with, retrieve, or alter user data other than the user that has been compromised.
How to Reduce the Likelihood of Remote Exploitation?
The only way to reduce the potential for adversaries to compromise the service ecosystem is to decrease the potential targets into a manageable set of services that can be quickly and easily maintained. The second most important augmentation to the architecture is the design of the underlying architecture: the execution architecture, operating system configuration, deployment toolchain, programming language security, and other options that define how securely an application may run.
- Define an Update Model
- Default-Open or Fail-Open Firewall Rules
- Rowhammer and Similar Attacks
- Virtual Machine Compromises
How Can the Service Manage User Privacy?
- Define a Third-Party Data Distribution Policy
- Build a Third-Party Data Filter
- Build an API for Users to Control Privacy Attributes
Critical Recommendations
- TCB The trusted computing base (TCB) of a computer system is the set of all hardware, firmware, and/or software components that are critical to its security, in the sense that bugs or vulnerabilities occurring inside the TCB might jeopardize the security properties of the entire system. The careful design and implementation of a systems trusted computing base is paramount to its overall security. Modern operating systems strive to reduce the size of the TCB so that an exhaustive examination of its code base. In order to reduce costs and security risks, the TCB should therefore be kept as small as possible. So, one of the first decisions that must be made is the boundary of the audit in terms of the list of system components that will come under scrutiny.(OS Web)
TODO:對關於安全的軟體,硬體,協議進行徹底檢測,因此size of TCB越小越好。
2. Define an Organizational Root of Trust An Organizational Root of Trust is a certificate or public-key based system for authenticating computing platform entities in an organization.
It will cryptographically validate that the messages were signed by the public key representing the system. Then, it will verify the signature the signing key generated of that system』s unique public key. Then, the client should verify that the signing key was indeed the signing key authenticated by the organizational root.
A service must be made available that verifies whether certificates have been revoked, or are currently valid. Another service may need to be used to authenticate the identities of servers or services with a short lifespan, depending on the requirements of the underlying infrastructure.
The risk of not using an organizational root of trust is that any compromise to a single key can result in compromise of the entire ecosystem. By separating the organization into a hierarchy, and deploying separate keys for the hierarchy, keys can be cycled at regular intervals and according to the priority of the application or sub-organization the key relates to.
3. Define a Bootstrap Method
In order for an application to run properly, it must be loaded and executed in a consistent way on a reliable, high quality, and secure platform. The TCB defines how to formulate this platform, but the Bootstrap model defines how the application shall be ran on top of it.
- Define how the application will authenticate Endpoints, Service Peers, and Partners
- Define what the application』s configuration should look like
- Enforce each different application to have a unique identity, especially applications running on separate tiers
An application』s configuration often determines how secure it is in production. A configuration should be enforced, and presented read-only to an application. The application, or someone abusing the application infrastructure, should not be able to simply alter the configuration of an application.
4. Define a Security Front-End for Public Systems
- DDoS-resistant infrastructure
- Load-Balancing infrastructure
- Redundancy systems
- Web Application Firewalls (optional)
- Traditional Firewalls
5. Define a Persistent Storage Model
If a secure persistent storage model isn』t defined, there will be no architecture that enforces unique per-user attributes to be securely separated from other assets. The result can be that any compromise of a token that grants an adversary access to a storage device may result in the compromise of multiple user』s data. A persistent storage model, however, can isolate the compromise to one single user, or a single storage technology with encrypted data. In either case, the scope of the compromise is significantly reduced, granting the organization more time to react and combat the threat to both users and the business.
TODO:如果有用戶被入侵,黑客所獲得的數據只能僅限於該用戶的數據,不能擴散到其他用戶
6. Define an Administration Model
Each system must be accessible by administration to troubleshoot and diagnose application faults. This can be challenging in environments where services or servers are short-lived, if an administrative model is not sufficiently designed. To accomplish this, identify how the administrative team will communicate with each system in each tier. There should be authentication boundaries, such as VPNs, that separate disparate systems from each other. Ensure the administrative team must authenticate through each tier.
Key:How changes can be made and must be tracked
7. Define a Systems Logging and Monitoring Model
- Increased network traffic
- Increased network traffic in an odd direction (especially egress)
- Egress network traffic from a resource that shouldn』t need egress
- Abnormal CPU utilization
- GPU utilization for systems with no visual interface, but have a GPU as a part of the CPU
- Disk or network-storage utilization
- Abnormal changes in system time on a particular host
TODO:監控系統資源的使用和數據量的流入流出
8. Define an Incident Response Model It isn』t enough to detect a potential compromise or an on-going attack. The organization must be able to react to, and combat, the attack. If a system is compromised, cleaning or shutting off that system is not enough. The organization must, instead, be able to diagnose the source of the compromise, patch the system, and deploy the patch on all existing infrastructure.
TODO:快速的攻擊響應和部署補丁
9. Define a Recovery Model
Regardless of whether a user or application is affected due to a security compromise or a hardware fault, a recovery must occur. A procedure should be put in place for recovery of information and capability within application tier. The procedure must be tailored to the context of each application and tier.
TODO:對被入侵後如何快速恢復系統和數據進行預案。(case:攜程資料庫被誤刪)
10. Define a Sunsetting Model
Every system that is deployed by an organization, and every tier used, has a lifetime. Even if the same product or service is deployed by the organization for decades, the technologies used to drive that product or service will change. Thus, there must not only be a plan for designing and implementing the product or service, there must be a plan to sunset that product or service.
This allows engineers and business leadership to migrate the technology over to a more suitable set of innovations without gaps in the underlying platforms. It also ensures that a product that will no longer be offered to partners and users will end its lifetime without the potential for exploitation by adversaries after the business closes down.
For example, a simple case is a domain for a particular product after a business』s acquisition by a parent company. If the product is renamed, and the domain is migrated to the parent company』s domain, an adversary may be able to take ownership of the now defunct domain. If the adversary can issue cryptographic certificates for that domain and still interact with deployed technology under that old domain, there will be a significant gap in security caused by a lack of procedure in the sunsetting of that product or service.
TODO:對目前使用技術和模型的生命周期進行管理,以及migrate後(對安全,對第三方)造成的影響。e.g Linux,Ngix
11. Define a Set of Security Classifications(不怕神一樣的對手,就怕豬一樣的隊友)
To properly manage interactions with Partner organizations effectively, security classifications must be defined. This will set the tone for not only the internal organizational policy on data security, but will help define the level of security Partner organizations apply to the business』s data, their own data, and customer』s data.
- Public - Any entity granted access
- Classified - User must authorize release
- Secret - User-specific data
- Top Secret - Organization-specific data, never to be released
TODO:1.將數據機密級別分出等級2.將人和第三方合作夥伴獲取數據的許可權分出等級。
12. Define Classifications for Sets of Data Types
This will enable the organization to clearly define what types of information are acquired, generated, and disseminated to peers in the IoT system, and how the organization should treat these types of data.
While the type identifies what the data represents and how it should be processed, the security class will represent how, where, and when the information can be used, and to whom it may be shared.
These classes define how the information should be used within the system, and what protections must be applied to the data in order to maintain an appropriate security posture.
TODO:決定了系統中流動和執行的數據類型,什麼數據應該生成,什麼數據應該傳播。這個數據應該做什麼,有沒有做他不應該做的事情。
High-Priority Recommendations
- Define a Clear Authorization Model While the privacy model deals with the way user』s information is offered to Partners, the authorization model defines how the business or Partners will act on behalf of a user. Allow the user to grant access, or revoke access, to certain capabilities on demand. Ensure that revoked capabilities take action immediately, to diminish the potential for abuse.
TODO:用戶有隨時允許和撤回授權的權利,撤回要迅速。e.g. Apple,限制第三方獲取不該獲取的數據,以防第三方被入侵危機雲端的安全
2. Manage the Cryptographic Architecture
- Their cryptographic algorithms have been deprecated
- They are using cryptographic keys with adequate bit-lengths
- Hashing algorithms are subject to collision attacks
- A strong random number generator is used e.Messages are sufficiently padded with random data
- Cryptographic protocols, such as TLS, are up-to-date with best practices
- Privacy-centric concepts, such as forward secrecy, are used
- Plaintext passwords or pin numbers are passed over the network i.A custom cryptographic algorithm was used
3. Provision Servers Server provisioning involves defining, configuring, personalizing, and deploying a server in a production environment. The provisioning process, from a service perspective, ensures that a server is security hardened and ready for deployment in an environment that may be potentially hostile.
+how to update it.
4. Implement Input Validation All data acquired from an endpoint, user, or purported user, must be analysed for anomalies.(e.g. SQL injection)
- Identify how the data shall be used internally
- Enforce a policy around what kinds of encodings and characters adhere to the internal use model
- Design an API that analyses the data according to this policy
- Raise an exception when data has been identified that breaks the model
- Log the event internally with metadata regarding the session to help detect adversarial behavior
5. Implement Output Filtering Output filtering is the complement to input validation. This process not only secures the presentation layer from adversarial manipulation, but also disallows the system from rending information to a user that should be deemed privileged.
all data to be rendered by the presentation layer must be assessed prior to it leaving the service layer.
TODO:與之前的data classification與a set of security classification相呼應,可以按照他們的規則構建filter。比如third party獲取了不該獲取的信息。
6. Enforce Strong Password Policy typically four ways an attacker will compromise a password:
- By stealing the password database and cracking individual passwords
- By brute-forcing the application authentication service
- By installing malware
- By using hard-coded or default passwords
7. Define Application Layer Authentication and Authorization
While these entities』 communications channels are secured with the Organizational Root of Trust, their actions and identities must be authenticated using a separate system.
Generally, this application layer authentication will be facilitated by the same service. However, information will be gathered from a separate resource. For example, it is best to place user and administrative authentication data in separate databases. This ensures that if there is a way to manipulate the database through the application layer (for example, using a SQL injection), attackers may only move laterally through the user database. They may not move vertically, elevating their privileges to administrator, without compromising the database, itself.
If possible, define separate storage systems for:
- Endpoint identities
- Users
- Administrator credentials
- Partners
8.Default-Openor Fail-Open Firewall Rules
推薦閱讀:
※自製蜜罐之前端部分
※DEFCON GROUP 010上竟玩了這些好玩的東西!
※繞過AppLocker系列之MSBuild的利用