Insecure Design was a new entry when the latest version of the OWASP Top Ten was released in 2021. An really, what it gets at is a good lesson – Designing an application with security in mind can go a long way in ensuring that the end product is robust against all sorts of vulnerabilities. This means that security should be taken into account during the design phase and not “baked in” after the product has been shipped.
And when we say “product” and “design phase” we just don’t mean an application. This could be the architecture of your whole monitoring and logging system. This could be a misconfiguration of your federated login system combined with overprivileged user accounts being able to access a service they aren’t supposed to access and this service hasn’t been updated in several years.
In Generic Terms, What is Insecure Design?
Insecure design refers to the architectural flaws in the development process where security has not been considered or has been inadequately addressed. Unlike a single code vulnerability, insecure design often means a systematic failure that exposes applications to various types of risks.
Real-World Examples
Example 1: The Ashley Madison Hack
One of the most infamous hacks that can be attributed to insecure design was the Ashley Madison hack in 2015. Ashley Madison, a site designed for married individuals to have extramarital affairs, was compromised, exposing millions of its users’ data.
Insecure Design Flaw: The platform stored sensitive user information, including payment details and real names, in an inadequately protected manner.
Mitigation: A secure design would have incorporated strong encryption for sensitive data and would have minimized data retention policies to only keep information as long as absolutely necessary.
Example 2: Equifax Data Breach
In 2017, Equifax, one of the largest credit reporting agencies, announced that it had suffered a data breach affecting more than 143 million U.S. consumers.
Insecure Design Flaw: The breach was possible because of a vulnerability in open-source software, Apache Struts, used by Equifax. While this was an implementation error, the insecure design part comes into play where Equifax did not have adequate monitoring and updating mechanisms in place.
Mitigation: A well-designed architecture would have included automated security patches, regular vulnerability assessments, and immediate alerts for suspicious activities.
Example 3: Mirai Botnet
The Mirai Botnet attacked various Internet of Things (IoT) devices, transforming them into a network of remotely controlled bots.
Insecure Design Flaw: Many IoT devices had built-in default usernames and passwords that were easy to guess.
Mitigation: Security by design should involve requiring the user to change the default credentials upon first use, along with implementing strong authentication mechanisms.
Best Practices for Secure Design
- Least Privilege Access: Design your system so that users and components have only the minimum levels of access — or permissions — they need to accomplish their tasks.
- Regular Audits: Implement a robust auditing and monitoring system to detect any unauthorized access or anomalies.
- Incorporate Security Early: Make security a part of the Software Development Life Cycle (SDLC), not just an afterthought. Perform threat modelling and design review early and often.
- Penetration Testing: Regular penetration tests will help you identify vulnerabilities.
So?
Insecure design was thrown in the Top Ten because, at the end of the day, the severity of most hacks are greatly enhanced by Insecure Design. A security-first approach to design can mitigate many of these risks and create a stronger, safer product.
As always, if you need an architecture review to ensure your design is secure, or simply a penetration test to see first hand what the bad guys can do, reach out to Brackish Security.
