About
A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.
Description
Insecure design focuses on the risks associated with design and architectural flaws and presents a wide range of disadvantages. It is a broad category representing various weaknesses expressed as "missing or ineffective control design".
But there is a difference between an uncertain design and an uncertain implementation. There is a reason why we distinguish between design and implementation flaws. A secure design can still have implementation flaws that lead to vulnerabilities. A dangerous design can not be fixed by perfect implementation, because the necessary security controls are not designed to defend against specific attacks. One of the factors that leads to design insecurity is the lack of business risk profiling inherent in the software or system being developed. This does not determine what level of security design is needed.
Requirements and Resource Management
Gather and negotiate with the company the business requirements for the application, including protection requirements for the confidentiality, integrity, availability and authenticity of all data assets and the expected business logic. Consider how exposed your application will be and whether you need tenant separation (in addition to access control). Draw up the technical requirements, including functional and non-functional safety requirements. Plan and negotiate a budget that covers all design, construction, testing, and operation, including security activities.
Secure design
Secure design is a culture and methodology that continuously assesses threats and ensures that code is robustly designed and tested to prevent known methods of attack. Threat modelling should be integrated into improvement sessions (or similar activities); look for changes in data flow and access control or other security controls. When developing a user story, define the correct flow and error states, ensure they are well understood and agreed by responsible and affected parties. Analyze the assumptions and conditions for the expected flows and error streams and ensure that they are still accurate and desirable. Determine how to validate assumptions and enforce the conditions necessary for correct behavior. Ensure that the results are documented in the user story. Learn from mistakes and offer positive incentives to encourage improvement. Secure Design is neither an add-on nor a tool that can be added to software.
Reference here.
Prevention
To protect your applications from unreliable planning, use the following best practices when planning your applications:
When defining user stories, analyse use cases together with abuse cases.
Define security rules, checks and access controls in each user story.
Apply the threat modelling assessment process for each component and function.
Write unit and integration tests to confirm that all critical flows are robust to the threat model.
Design tenant insulation in all layers.
Limit resource consumption per user and per service.
Reference here.
Potential impact
Insecure application design can have severe consequences for the business, as it may allow attackers interfere with the application logic and lead to sensitive information disclosure or web application compromise.
Recent cases of IDOR vulnerabilities in WordPress plugins demonstrate how easy it is to take over the web application.
Reference here.
Common examples
Example #1: CWE-209(Generation of Error Message Containing Sensitive Information).
It is possible that the software will emit an error message that contains sensitive information about its surroundings, users, or other linked data when the error occurs due to an invalid inputs or accessing a resource to which we doesn’t have access.
Example #2: CWE-256(Unprotected Storage of Credentials):
Storing a password in plaintext may result in the compromising of the entire system.
Example #3: (Trust Boundary Violation)
The product combines trusted and untrusted data in the same data structure or structured message.
Example 4: CWE-522( Insufficiently Protected Credentials)
Although the product transmits or saves authentication credentials, it does so in an insecure manner that makes it vulnerable to unauthorized interception and/or retrieval of the credentials.
Reference here.
Cases
A good example of recent insecure design has prevented PC users and PC gamers from buying new Nvidia GPUs at recommended retail prices. Many e-commerce sites did not take into account the protection against bots, which were used by scalpers to buy back their entire stocks, which were initially limited. The scalpers then resold the cards at extremely high prices on auction sites, meaning that those who really needed to get a new GPU had to pay prices several times higher than the recommended retail price.
____________________________________________________________________________________________
References:
Last updated
Was this helpful?