The IEEE has just set up a Center for Secure Design to help software architects create applications that don’t have fatal flaws. Many are well known, but for some reason continue to persist. What they created is a list of the top 10 design flaws and how to avoid them. Images from Shutterstock.com
Earn or give, but never assume trust
Designs that place authorization, access control, enforcement of security policy or embedded sensitive data in client software thinking it won’t be discovered are inherently weak. But if it has to be, design the system to cope with potential compromise – – for example, set expiration dates for data stored in the client.
Authenticate with a tamper-free mechanism
Authentication mechanisms are critical to secure designs. A single authentication mechanism should leverage one or more factors as per an application’s requirements, that it serve as a choke point to avoid potential bypass and that authentication credentials have limited lifetimes.
Authorize after authenticate
Authorization should be conducted as an explicit check even after authentication – for example, after authenticating to a bank machine the user may still be limited to certain actions, like withdrawing a maximum amount a day. For sensitive operations, two people may need to be authenticated.
Keep control
Don’t co-mingle data and control instructions in a single entity, like a string. This is a general problem that manifests itself at several abstraction layers, from low-level machine instructions and hardware support to high level virtual machine interpreters and APIs that consume domain-specific language expressions.
Validate all data assumptions
For example, Web applications should use a request filter or interceptor facility provided by the underlying framework to centrally intercept all incoming requests and apply basic input validation to all request parameters.
Use cryptography correctly
Cryptography is so hard to get right that it always makes sense to work with an expert if you can. This expert should work with your designers to provide an API abstraction around a strong library so developers aren’t making decisions on algorithms and cipher modes.
Identify and protect sensitive data
Data sensitivity is context-sensitive and depends on regulation, company policy, contractual obligations and user expectation. Creating a policy that identifies different levels of classification is the first step in handling data appropriately. As for protection, remember that for some data confidentiality is critical; for others availability, and others data integrity.
Always consider the users
A series of complex trade-offs: All security-related mechanisms need to be designed in a way that makes it easy to deploy, configure, use and update the system securely. When in doubt, make a system secure by default. If users want to change something, make it easy to find.
External components increase risk
It’s unlikely you’ll develop a new system without using external pieces of software from another team or from a third party. But understand the risks and take steps to mitigate them, such as enabling only the functions you need.
Be flexible
Software security must be designed for change. While during the design software has to been a set of requirements, the software, environments, threats and attacks change over time. So design for secure updates, with the ability to isolate or toggle functionality and for changes in the security properties of components beyond your control.
