All software has defects, especially in today’s complex code with thousands of lines that have to be worded just so. Electrical and Electronics Engineers (IEEE) is aware of this dilemma. After much deliberation, the group gathered its thoughts in a paper, “Avoiding the Top 10 Software Security Design Flaws.” IEEE mentioned that many of the flaws that made the list have been well known for decades, but continue to be a problem. Here we’ll take a look at those flaws – and how to fix them.

Tips for Avoiding Key Software Flaws

>>> Readmore: Vietnam – The perfect choice for software outsourcing

Authorize after authenticate

Authorize is different from authenticate. For instance, debit cards and PINs authenticate ATM users. However, authenticated ATM users are only authorized to withdraw money from their accounts. CSD believes that authorizing should be considered an explicit check using a common infrastructure (system library or back end) that defines the privileges and services allowed.

Earn or give – but never assume – trust

Software systems often need information from other software packages or users. For example, server and client applications. The system software may at first be secure, but if any component is insecure, the system software will inherit that insecurity. CSD stressed the importance of inventorying all the components that communicate with the software in question. Then methods must be devised to validate the discovered components.

Handle identity-sensitive data with care

Two things happen; designers fail to identify data as sensitive, or designers do not determine all the ways in which data can be exposed or manipulated. CSD proposes creating a data-sensitivity policy that addresses all company-specific factors. The policy should include:

• Information about government and industry regulations that apply to the organization
• Whether or not data confidentiality applies
• How data is handled when it’s in transition

Be flexible when considering future changes to objects and actors

Assuming that a software program’s code is static is asking for trouble. Software of note is under constant revision. Knowing that, the important question then becomes, how software changes affect security. To that end, CSD suggests keeping the following in mind. Design for:

• Security properties changing over time, such as when code is updated
• The ability to isolate or toggle functionality
• Changes to objects intended to be kept secret
• Changes in the security properties of components beyond your control

Always consider the users

Developers’ failure to consider users can lead to many issues, including:

• Privilege escalation
• Users disclosing sensitive information
• Complicated security procedures that improve the odds of incorrect or lack of use.

CSD is aware that security versus convenience is an issue. Using a risk assessment approach (making trade-offs) may not be perfect, but it’s better than ignoring users altogether.

IEEE’s Center for Secure Design has moved the bar from bugs to flaws. Only time will tell whether their suggestions will have an impact.

(techopedia)