From 40622591dea931e94eb55fe330d1b2ad8fa729b3 Mon Sep 17 00:00:00 2001 From: TimmyBc Date: Mon, 25 Mar 2024 20:33:57 +0100 Subject: [PATCH] Update remediation_advice.json --- .../remediation_advice.json | 33 ++++++++++++++----- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/mappings/remediation_advice/remediation_advice.json b/mappings/remediation_advice/remediation_advice.json index db272cc..42531d7 100644 --- a/mappings/remediation_advice/remediation_advice.json +++ b/mappings/remediation_advice/remediation_advice.json @@ -1144,7 +1144,30 @@ "https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection" ] }, - + { + "id": "physical_security_issues", + "children": [ + { + "id": "weakness_in_physical_access_control", + "children": [ + { + "id": "cloneable_key", + "remediation_advice": "The 2 most effective are interative locking elements (which can be defeated still by a skilled attacker) or usage of digital key systems such as Assa eCLIQ or Pulse" + }, + { + "id": "commonly_keyed_system", + "remediation_advice": "Unique keys should be used on any system which intends to be secure, otherwise if keyed to a common key system, the risk needs to be accepted that the key could be obtained if the lock doesn't secure a secure component." + }, + { + "id": "master_key_identification", + "remediation_advice": "While physical lock systems require the key material to be inside the lock, electonic access control systems can use cryptographicly strong key mechanisms which prevent the key material from being accessable on the device" + } + ], + "id": "bypass_of_physical_access_control", + "remediation_advice": "" + } + ] + }, { "id": "insecure_os_firmware", "children": [ @@ -1184,14 +1207,6 @@ "id": "failure_to_remove_sensitive_artifacts_from_disk", "remediation_advice": "Implement robust deletion functions which not only reference to the data, but write over the existing data to prevent digital forensic methods of recovery" }, - { - "id": "hardcoded_password", - "remediation_advice": "1. Never use a hardcoded password within the source code. Many times, the application can be disassembled or decompiled after it has been compiled. This will likely reveal the hardcoded password string to an attacker.\n2. Never use a password string. Instead, use a random salt per user with the password string and run it through a cryptographically strong hashing algorithm.\n3. Store the salt and the hashed password server-side and do the check there. Never check the password on the client side.", - "references": [ - "https://www.owasp.org/index.php/Password_Management:_Hardcoded_Password", - "https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md" - ] - }, { "id": "kiosk_escape", "remediation_advice": "1. Implement vigirous QA testing of applications prior to deployment\n2. Implement robust error logging and catching within the application to prevent crashes\n3. Initiate application restarts in the event of a application crash.\n4. Use Lower Privleged accounts with minimal permissions to lower the impact of a potential kiosk escape"