Change logical access to authorization access

Logical access levels have been changes to authorization levels
Test cases access abbreviations have also been made LA-1 >> AA-1

Updated the markdown checklist input validation from INVAL to INPV

checklists/checklist.md

@@ -89,9 +89,9 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 |IOT-DES-CRYPT-001|Usage of Weak Cryptographic Algorithms|||
 |**IOT-DES-LOGIC**|**Business Logic**|||
 |IOT-DES-LOGIC-001|Circumvention of the Intended Business Logic|||
-|**IOT-DES-INVAL**|**Input Validation**|||
-|IOT-DES-INVAL-001|Insufficient Input Validation|||
-|IOT-DES-INVAL-002|Code or Command Injection|||
+|**IOT-DES-INPV**|**Input Validation**|||
+|IOT-DES-INPV-001|Insufficient Input Validation|||
+|IOT-DES-INPV-002|Code or Command Injection|||
 
 ## Internal Interfaces (IOT-INT)
 |Test ID|Test Name|Status|Notes|
@@ -112,9 +112,9 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 |IOT-INT-CRYPT-001|Usage of Weak Cryptographic Algorithms|||
 |**IOT-INT-LOGIC**|**Business Logic**|||
 |IOT-INT-LOGIC-001|Circumvention of the Intended Business Logic|||
-|**IOT-INT-INVAL**|**Input Validation**|||
-|IOT-INT-INVAL-001|Insufficient Input Validation|||
-|IOT-INT-INVAL-002|Code or Command Injection|||
+|**IOT-INT-INPV**|**Input Validation**|||
+|IOT-INT-INPV-001|Insufficient Input Validation|||
+|IOT-INT-INPV-002|Code or Command Injection|||
 
 ## Physical Interfaces (IOT-PHY)
 |Test ID|Test Name|Status|Notes|
@@ -135,9 +135,9 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 |IOT-PHY-CRYPT-001|Usage of Weak Cryptographic Algorithms|||
 |**IOT-PHY-LOGIC**|**Business Logic**|||
 |IOT-PHY-LOGIC-001|Circumvention of the Intended Business Logic|||
-|**IOT-PHY-INVAL**|**Input Validation**|||
-|IOT-PHY-INVAL-001|Insufficient Input Validation|||
-|IOT-PHY-INVAL-002|Code or Command Injection|||
+|**IOT-PHY-INPV**|**Input Validation**|||
+|IOT-PHY-INPV-001|Insufficient Input Validation|||
+|IOT-PHY-INPV-002|Code or Command Injection|||
 
 ## Wireless Interfaces (IOT-WRLS)
 |Test ID|Test Name|Status|Notes|
@@ -158,9 +158,9 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 |IOT-WRLS-CRYPT-001|Usage of Weak Cryptographic Algorithms|||
 |**IOT-WRLS-LOGIC**|**Business Logic**|||
 |IOT-WRLS-LOGIC-001|Circumvention of the Intended Business Logic|||
-|**IOT-WRLS-INVAL**|**Input Validation**|||
-|IOT-WRLS-INVAL-001|Insufficient Input Validation|||
-|IOT-WRLS-INVAL-002|Code or Command Injection|||
+|**IOT-WRLS-INPV**|**Input Validation**|||
+|IOT-WRLS-INPV-001|Insufficient Input Validation|||
+|IOT-WRLS-INPV-002|Code or Command Injection|||
 
 ## User Interfaces (IOT-UI)
 |Test ID|Test Name|Status|Notes|
@@ -181,6 +181,6 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 |IOT-UI-CRYPT-001|Usage of Weak Cryptographic Algorithms|||
 |**IOT-UI-LOGIC**|**Business Logic**|||
 |IOT-UI-LOGIC-001|Circumvention of the Intended Business Logic|||
-|**IOT-UI-INVAL**|**Input Validation**|||
-|IOT-UI-INVAL-001|Insufficient Input Validation|||
-|IOT-UI-INVAL-002|Code or Command Injection|||
+|**IOT-UI-INPV**|**Input Validation**|||
+|IOT-UI-INPV-001|Insufficient Input Validation|||
+|IOT-UI-INPV-002|Code or Command Injection|||

src/01_introduction/README.md

@@ -4,7 +4,7 @@
 
 The networking of a multitude of different devices towards the Internet of Things (IoT) poses new challenges for manufacturers and operators of respective solutions. Due to the interconnection of many different technologies, standards and protocols, a considerable amount of effort is necessary to build up and maintain a homogeneous level of network security, data security and IT security in general. Additionally, since the IoT field is changing and developing quickly, manufacturers and operators must continuously monitor potential threats to their devices and networks.
 
-While conventionally networked computer systems can be secured with established methods, e.g., restricting physical and logical access to networks and important systems, these methods can be difficult to apply to IoT devices and ecosystems due to the above-mentioned heterogeneity and new network layouts. Compared to conventional computer networks, IoT infrastructures can be very wide-spread. Even though the back end infrastructure might be similar to conventional computer networks, IoT devices could be located at an arbitrary location, possibly even outside of a secure zone of the operator. In some cases, the devices are even physically accessible to third parties and potential attackers, e.g., connected cars, smart home devices or package stations. Hence, every IoT device represents a potential threat to user data and the entire infrastructure since a single manipulated device is sufficient to endanger the entire ecosystem.
+While conventionally networked computer systems can be secured with established methods, e.g., restricting physical and authorization access to networks and important systems, these methods can be difficult to apply to IoT devices and ecosystems due to the above-mentioned heterogeneity and new network layouts. Compared to conventional computer networks, IoT infrastructures can be very wide-spread. Even though the back end infrastructure might be similar to conventional computer networks, IoT devices could be located at an arbitrary location, possibly even outside of a secure zone of the operator. In some cases, the devices are even physically accessible to third parties and potential attackers, e.g., connected cars, smart home devices or package stations. Hence, every IoT device represents a potential threat to user data and the entire infrastructure since a single manipulated device is sufficient to endanger the entire ecosystem.
 
 In order to reduce the risk of successful attacks, manufacturers and operators should periodically assess the security level of their IoT solutions. An instrument for this purpose is penetration testing. The goal of a penetration test is to identify security vulnerabilities within IoT solutions. The results can be used to address the detected vulnerabilities and thus strengthen the security level.
 

src/02_framework/attacker_model.md

@@ -25,7 +25,7 @@ The CVSS defines the following exploitability metrics:
 
 -   **Attack complexity:** "This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability" ([source][cvss]). The attack complexity is not used in the attacker model since it refers to "conditions beyond the attacker's control" ([source][cvss]) and thus is not relevant for categorizing potential attackers.
 
--   **Privileges required:** "This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability" ([source][cvss]). Values for this metric are ranging from none (no privileges) to high. The required privileges are represented in the attacker model by the logical access level.
+-   **Privileges required:** "This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability" ([source][cvss]). Values for this metric are ranging from none (no privileges) to high. The required privileges are represented in the attacker model by the authorization access level.
 
 -   **User interaction:** "This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component" ([source][cvss]). The necessity of interactions by legitimate users will not be considered in the attacker model since, while being relevant for the exploitability of a vulnerability, it is not relevant for the selection of applicable test cases.
 
@@ -35,7 +35,7 @@ The CVSS defines the following exploitability metrics:
 
 ## Access Levels
 
-Within this attacker model, access levels are a measure for the relation between a certain group of individuals (access group) and the IoT device. They describe how individuals of the access group are intended to be able to interact with the device. These can either be physical interactions or logical interactions.
+Within this attacker model, access levels are a measure for the relation between a certain group of individuals (access group) and the IoT device. They describe how individuals of the access group are intended to be able to interact with the device. These can either be physical interactions or logical authorization interactions.
 
 The degree of how close individuals can get to the device is measured by the physical access level. The physical access level is an adaption of the CVSS metric "attack vector" and it reflects the physical context that is required to perform attacks against a target device. Therefore, some of the original values from the CVSS were used (network, local, physical). However, the description of local access was adjusted in regards of the focus on the physical context. Additionally, the physical access as defined in the CVSS was split into two levels: non-invasive and invasive physical access. The reason for this is that some IoT devices are protected with special measures that restrict access to device-internal elements, e.g., locked or sealed enclosures. In this case, attackers might not be able to access device-internals in a reasonable amount of time, thus they only have non-invasive physical access. Other devices have enclosures that can be opened in a short time, e.g., by removing screws. Thus, attackers could access device-internals, therefore gaining invasive physical access. Overall, the physical access level can be affected by factors like geographical location, building security or the device enclosure.
 
@@ -49,37 +49,37 @@ The following physical access levels are defined:
 
 4.  **Invasive access (*PA-4*):** There is no physical distance between an individual and the device and the individual can directly access device-internal elements in a physical manner (i.e., open the device enclosure).
 
-The digital privileges of individuals are measured by the logical access level. The logical access level is an adaption of the CVSS metric "privileges required". In addition to the values, defined in the CVSS, another level of privileges, called manufacturer-level access, was added on top of the high privileges. Contrary to web applications and computer networks, which are usually operated from within the control zone of the operator (e.g., within a data center), IoT devices are often operated outside that control zone. Established methods for securing maintenance and debugging access (e.g., restricting maintenance access to pre-defined subnets, IP addresses or physical ports in the data center) can not always be applied. Hence, attacks against a device with manufacturer-level access might be possible. Overall, the logical access level can be affected by factors like policies or role-based access models.
+The digital privileges of individuals are measured by the authorization access level. The authorization access level is an adaption of the CVSS metric "privileges required". In addition to the values, defined in the CVSS, another level of privileges, called manufacturer-level access, was added on top of the high privileges. Contrary to web applications and computer networks, which are usually operated from within the control zone of the operator (e.g., within a data center), IoT devices are often operated outside that control zone. Established methods for securing maintenance and debugging access (e.g., restricting maintenance access to pre-defined subnets, IP addresses or physical ports in the data center) can not always be applied. Hence, attacks against a device with manufacturer-level access might be possible. Overall, the authorization access level can be affected by factors like policies or role-based access models.
 
-The following logical access levels are defined:
+The following authorization access levels are defined:
 
-1.  **Unauthorized access (*LA-1*):** An individual can get anonymous access to the device component. Attackers with anonymous access can be any unregistered user.
+1.  **Unauthorized access (*AA-1*):** An individual can get anonymous access to the device component. Attackers with anonymous access can be any unregistered user.
 
-2.  **Low-privileged access (*LA-2*):** An individual can only get access to the device component, if it is authenticated and in possession of standard privileges. Attackers with low-privileged access can be any registered user.
+2.  **Low-privileged access (*AA-2*):** An individual can only get access to the device component, if it is authenticated and in possession of standard authorization privileges. Attackers with low-privileged access can be any registered user.
 
-3.  **High-privileged access (*LA-3*):** An individual can only get access to the device component, if it is authenticated and in possession of extensive privileges. The term "extensive privileges" means that individuals have access to restricted functionalities that are not available to all registered users of the device component (e.g., configuration settings).
+3.  **High-privileged access (*AA-3*):** An individual can only get access to the device component, if it is authenticated and in possession of extensive privileges. The term "extensive privileges" means that individuals have access to restricted functionalities that are not available to all registered users of the device component (e.g., configuration settings).
 
-4.  **Manufacturer-level access (*LA-4*):** An individual can only get access to the device component, if it is authenticated and in possession of manufacturer-level privileges. Contrary to high-privileged access, manufacturer-level access is not restricted in any way and includes, e.g., debugging access for developers of the device, access to the source code or root-level access to the firmware.
+4.  **Manufacturer-level access (*AA-4*):** An individual can only get access to the device component, if it is authenticated and in possession of manufacturer-level authorization privileges. Contrary to high-privileged access, manufacturer-level access is not restricted in any way and includes, e.g., debugging access for developers of the device, access to the source code or root-level access to the firmware.
 
 [^2]: Limited physical distance is not restricted to a specic maximum value per se. Depending on the technologies in use, the maximum distance might range from a few meters (e.g., in case of Bluetooth) to a few kilometers (e.g., in case of LTE).
 
 
 
 ## Mapping of Device Components and Access Levels
 
-The perspective of the testers during the test will be determined by minimal and maximal access levels, chosen as a baseline for the test. Physical and logical access levels have different impacts on the penetration test and its scope.
+The perspective of the testers during the test will be determined by minimal and maximal access levels, chosen as a baseline for the test. Physical and authorization access levels have different impacts on the penetration test and its scope.
 
 **Physical access level:**
 
 -   The physical access level refers to the device as a whole. Thus, some physical access levels directly define that certain device components can not be tested with the given level since an attacker could not interact with these components at all. The relation between physical access levels and device components is shown in the table below.
 
 -   Based on the specific requirements of a manufacturer or operator, the minimal and/or maximal physical access levels might be hard boundaries for the test execution since the contractee might want to specifically exclude certain tests, e.g., those which require invasive physical access.
 
-**Logical access level:**
+**Authorization access level:**
 
--   Since logical access might be handled differently across multiple device components, the logical access level rather refers to access to an individual component than to the device as a whole. Thus, the impact of logical access levels on the test scope always depends on the specific implementation of the business logic and the authorization/permission scheme per component.
+-   Since authorization access might be handled differently across multiple device components, the authorization access level rather refers to access to an individual component than to the device as a whole. Thus, the impact of authorization access levels on the test scope always depends on the specific implementation of the business logic and the AuthZ/permission scheme per component.
 
--   There is no reason for selecting a minimal logical access level for the test perspective since evaluating whether it is possible to get access to (parts of) the device with lower privileges than intended should be part of the test.
+-   There is no reason for selecting a minimal authorization access level for the test perspective since evaluating whether it is possible to get access to (parts of) the device with lower privileges than intended should be part of the test.
 
 All in all, the attacker model can be used to create an abstract representation of potential attackers. It can be used to describe which kind of attackers is considered a threat to a given device in its operation environment. Contrary to other methodologies and models, this one can be used in a more streamlined manner, thus being more efficient, e.g., compared to full threat and risk analysis approaches. It is also takes the specifics of the IoT context more into account than the CVSS, which it is based on. In combination with the device model, it is possible to define the test scope and test perspective, thereby determining which test cases can and shall be performed.