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.
INSIDE SLIDE Trust graphic SHUTTERSTOCK

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.

INSIDE SLIDE Keyboard with lock and chain

 


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.

INSIDE SLIDE Authorized graphic SHUTTERSTOCK


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.

INSIDE Stop SHUTTERSTOCK


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.

 

INSIDE SLIDE Approved stamp

 


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.

INSIDE SLIDE Encryption red SHUTTERSTOCK


 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.

 

INSIDE slide protect SHUTTERSTOCK


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.

INSIDE SLIDE controls SHUTTERSTOCK


 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.

INSID SLIDE risk dial SHUTTERSTOCK

 


 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.

INSIDE SLIDE flexibility SHUTTESTOCK


Previous articleSix tips for taming Shadow IT
Next articleCIO Innovation Summit in pictures
Howard Solomon
Currently a freelance writer, I'm the former editor of ITWorldCanada.com and Computing Canada. An IT journalist since 1997, I've written for several of ITWC's sister publications including ITBusiness.ca and Computer Dealer News. Before that I was a staff reporter at the Calgary Herald and the Brampton (Ont.) Daily Times. I can be reached at hsolomon [@] soloreporter.com