The community has a new login process
The community single sign-on system has been changed. Learn more about it HERE

Security Fundamentals Part 1: Fail Open vs. Fail Closed

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
0 0 23.6K

An understanding of core security fundamentals should not be limited to security teams and penetration testers, but it should also be essential knowledge for developers and application teams.  Whether testing an application for security vulnerabilities or coding functions of a new system, core security concepts should be deep-rooted in one’s mind.  

Many application teams have not been through core security training.  During development of new applications, they often make incorrect assumptions that lead to security vulnerabilities.  This seems to be particularly true of mobile development teams who are often rapidly building apps.  

In this series we will explore several core security concepts and discuss how they relate not just to security teams but also to software development teams.  Part one covers the concept of Fail Open vs. Fail Closed

In application development the concept of Fail Open vs. Fail Closed typically relates to how an application should behave when errors and exceptions are encountered.  When exceptions are thrown, Fail Open systems allow access as opposed to Fail Closed systems that block access

When handling errors, developers need to carefully choose what actions to take.  In deciding whether to fail open or to fail closed, the outcomes of each must be considered.  There are situations where each could be considered more secure than the other.  These cases differ and must be decided on an individual basis. 

Consider a shopping application that sells music.  If a user is purchasing a digital album that will be immediately available for download, what should the application do if an error is encountered while attempting to verify the user’s credit card?  Most likely, the application should fail closed and not allow the user access to the digital download.  The store would likely not want to give the music away until payment is verified.  

In the same application, suppose a user purchases a vinyl album that will be shipped after purchase.  If an error is again encountered during the verification of the user’s credit card, the application may wish to fail open.  In this case, the music store may be able to reattempt the credit card verification before the vinyl album is shipped.  Failing closed in this situation could cost the music store business. 

As illustrated in the music store example, there are situations where it is more appropriate to fail open and situations where it is more appropriate to fail closed.  If these situations are not analyzed, serious logical security flaws could be introduced.  

Often during application development, explicit error handling behaviors are not thought out.  When there is not a detailed fail open or fail closed requirement, error handling behaviors could introduce logical security flaws. 

Developers and application teams need to be trained in core security concepts.  Making incorrect security assumptions could lead to serious vulnerabilities.  Understanding the idea of Fail Open vs. Fail Closed helps ensure secure development. 

Fortify is the market leader, as confirmed by the Gartner Magic Quadrant, that gives customers the choice of on-premise, as-a-service, or a combination of both to assess, assure, and protect applications.  To learn more about Application Security Testing with Fortify, visit www.microfocus.com/appsecurity.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.