The significance of application security has skyrocketed in recent years. The more important and numerous applications become, the more companies rely on these resources, and the greater the risk if a security breach were to occur. Cybercriminals are always on the lookout for new opportunities to obtain potentially valuable information and other corporate assets. As the cybersecurity landscape changes, so, too, will their tactics and strategies.
Among the most important developments in this regard is the revelation of the Heartbleed vulnerability. As TechTarget contributor Michael Cobb recently highlighted, this incident should encourage virtually every company to reconsider its application security policies, especially in regard to open source and third-party components.
As Cobb pointed out, budget constraints are causing many enterprises to turn to open source libraries and third-party components with increasing regularity when developing complex applications. There's nothing wrong with these approaches – on the contrary, this can be an extremely effective, cost-efficient means of app development. But as Cobb asserted, many companies do not apply sufficient attention to security when leveraging such resources. They tend to be much more rigorous in regard to internally developed software.
Another key issue concerns older applications, databases and software systems and tools. Cobb asserted that in many cases, companies continue to leverage these resources for a long time – well after the individual responsible for creating or procuring the asset left the organization. Current workers simply assume that because this code was previously vetted by someone in the organization, it must still be reliable and secure.
However, as Cobb pointed out, the Heartbleed OpenSSL flaw demonstrated very clearly the danger of assuming but not verifying that a code is secure. It was precisely this type of thinking that led so many companies to use the encryption software without performing their own checks, thereby putting a tremendous amount of sensitive data at risk of loss or theft.
Better practices needed
In the face of these challenges, corporate CISOs need to reevaluate their application security strategies and policies, Cobb asserted. These strategies must strike a balance between minimizing risk and maximizing development teams' productivity.
This can be a difficult objective to achieve, and many organizations do not put in the necessary effort. The writer cited a recent survey which found that among 3,353 respondents, only 75 percent of their organizations had policies in place that concerned code and component use. Of these, 8 percent said the policies are not enforced. Furthermore, more than three-fourths of respondents said that their organizations had never banned the use of an open source component, despite the fact that almost one-third had suffered a data breach that was likely caused by open source software.
These statistics highlight the incongruity between many companies application security policies and the realities of the danger posed by poor practices.
To overcome these challenges, Gary McGraw, chief technology officer at Cigital, recommended that firms create a Software Security Group. This group should act as an intermediary between the security and development teams, reducing the tendency for each of these teams to become siloed. Ultimately, the goal should be for the development team to play an important role in software security standards creation from the very beginning.
Additionally, it is critical for businesses to ensure that their developers have access to high-quality application security tools, such as static code analysis and open source scanning solutions. These resources can help developers to reduce testing costs and increase productivity while simultaneously increasing the overall quality of application security throughout the organization as a whole.