|
Threats to information technology are rampant. Worms and viruses continue to propagate throughout networks. Hacking is now a tool of organized crime. The specter of cyber-terrorism continues to cast its shadow over the operations of many industries. Security and risk management remain as high profile issues for your board and executive teams.
Worst of all? The odds are excellent your most critical IT asset lies virtually unprotected. It’s your software – and the valuable data it manipulates, the intellectual property it embodies, and the business processes – and competitive differentiation – it enables. It’s tempting to reject this assertion out of hand. After all, you’ve deployed a comprehensive array of network security technologies. You’re spending significant levels of time and effort on identifying, tracking and patching vulnerabilities throughout your software infrastructure. Surely with all that effort you’re protected, right?
The unfortunate answer is “probably not.” For many, the emphasis on network perimeter protection and the never-ending chase to patch vulnerabilities consume your attention and efforts. As a result, you’re left blind to the risks posed by proprietary applications and systems developed and implemented by your own staff. Those systems deliver the bulk of the value many organizations receive from their IT investments. But they also represent the greatest source of financial risk, the most likely avenue for failure to comply with governmental regulations and provide the greatest potential for embarrassment in the case of exploit or attack.
Today’s business models clash with traditional network security approaches. Those models emphasize establishing – and protecting – perimeters to “keep the bad guys out.” Today’s reality is openness and collaboration with partners and customers. This reality has left attackers free to focus on the high-value targets that lie within our increasingly porous networks.
Many have turned to vulnerability management as an answer. But vulnerability management systems only address commercial software and applications. They do nothing to address vulnerabilities in internally developed applications. If anything, the ongoing demand for vulnerability management only confirms that as an industry, we’re not getting software security “right.” And, if the world’s leading software development organizations can’t yet get it right, what do you think the odds are of your organization achieving the goal?
Getting to the Root of the Problem
The good news is that anticipating appropriate security requirements – and ensuring they’re properly implemented – isn’t technically difficult, and requires less effort and expense than you might first expect. It does require organizational change, which can be a significant challenge. However, the rewards can be tremendous.
Countless studies – and common sense – reveal that identifying and correcting problems early in the application development lifecycle pays tremendous rewards. According to Gartner, “if 50 percent of software vulnerabilities were removed prior to production use for purchased and internally developed software, enterprise configuration management costs and incident response costs would be reduced by 75 percent each.” A recent NIST study shows an inexorable rise in remediation costs as software moves toward deployment -- 30 times the cost of fixing a problem early in the lifecycle.
With the typical reactive approach to software security, the topic often isn’t considered until just prior to deployment. A completed – or nearly completed – application is subjected to penetration testing or a manual code audit. Time-consuming and expensive, these approaches invariably find at least one critical security problem, prompting expensive re-work and deployment delays.
In the best case with this approach, developers are trained to view security as something to get through, around or under; engendering a counterproductive attitude. Perhaps the worst case arises when – as a result of deadlines, competitive pressures or business imperatives – insecure applications are deployed in spite of known weaknesses.
How can you begin to incorporate security into the foundation of your application development and deployment efforts? Experience with a number of different organizations has revealed three critical elements of an application security solution: process, automation and expert guidance.
Process
In quality assurance circles, it’s axiomatic that you can’t “test in” quality. The same holds true for application security. Testing can identify programmer or administrative missteps, and can verify that security requirements have been properly implemented. But significant and sustainable improvements require that application architects and developers consider, from day one, an application’s needs for confidentiality, access controls, authentication and integrity, availability and non-repudiation.
Articulating those needs can, at first glance, appear to be a daunting task. But by breaking application security into discrete tasks, distributed throughout the application development lifecycle, the effort becomes much more achievable.
To help, several security and software vendors have teamed to develop CLASP– the Comprehensive Lightweight Application Security Process, a standard in waiting for building security process into the application development lifecycle. Clearly, application security is a big job – so CLASP covers a lot of ground, throughout the application development lifecycle, from initial planning to post-deployment. The outgrowth of years of research, and hands-on experience with some of industry’s most demanding application development and security practitioners, CLASP provides guidance on two dozen different activities that support improved application security and integrity.
But CLASP also reflects the reality that organizations have already implemented their own application development processes, and security-related activities must be easily integrated into those existing processes if they are to stand a chance of being embraced and adopted by a development organization. So CLASP’s authors have divided these 24 activities into discrete components, and linked them with specific individuals involved in application development. CLASP provides guidance to auditors, developers, architects, testers and others in a form that is easy to adopt, so incremental improvements are readily achieved.
CLASP Best Practices
Reviewing CLASP’s Best Practices provides a high-level overview of the types of activities your organization should be considering in efforts to enhance application security:
Institute awareness programs – Essential security concepts and techniques may be foreign to your developers, and others involved in application development and deployment. So it’s imperative at the outset to educate everyone involved. It’s critical that project managers – as the driving force behind most application development or upgrade projects – consider security to be an important project goal, both through training and accountability. Awareness programs can be readily implemented, using external expert resources as appropriate, and deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively.
Perform application assessments – While it’s true you can’t test security into an application, application testing and assessments should still be a central component of your overall security strategy. Assessments, particularly automated tests, can find security problems not detected during code or implementation reviews, find security risks introduced by the operational environment, and act as a defense-in-depth mechanism by catching failures in design, specification or implementation. Test and assessment functions are typically owned by a test analyst or by the QA organization, but can – and should – span the entire life cycle.
Capture security requirements - Ensure that security requirementshave the same level of “citizenship” as all other “must haves.” It’s easy for application architects and project managers to focus on functionally when defining requirements – they do, after all, support the greater purpose of the application to deliver value to the organization. Security considerations can easily go by the wayside. So it’s crucial that security requirements be an explicit part of any application development effort. Among the factors to be considered:
- An understanding of how applications will be used, and how they might be misused or attacked.
- The assets (data and services) that the application will access or provide, and what level of protection is appropriate given your organization’s appetite for risk, regulations you are subject to, and the potential impact on your reputation should an application be exploited.
- The architecture of the application and probable attack vectors.
- Potential compensating controls, and their cost and effectiveness.
Implement secure development practices – Defined security activities, artifacts, guidelines and continuous reinforcement should become part of your organization’s overall culture.
Build vulnerability remediation procedures – Especially important in the context of application updates and enhancements, you must define what steps will be taken to identify, assess, prioritize and remediate vulnerabilities.
Define and monitor metrics – As we all know, you can’t manage what you can’t measure. Unfortunately, implementing an effective metrics monitoring effort can be a difficult undertaking. Despite this, metrics are an essential element of your overall application security effort. They are crucial in assessing the current security posture of your organization, help focus attention on the most critical vulnerabilities, and reveal how well – or poorly – your investments in improved security are performing.
Publish operational security guidelines – Security, perhaps obviously, doesn’t end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those tasked with monitoring and managing the security of running systems with advice and guidance on the security requirements your application demands, and how best to make use of the capabilities you’ve built into your application.
Desk checks, walkthroughs and audits are traditionally how most organizations identify potential security problems in source code and applications. And without a doubt, the insights and experience of skilled developers, analysts and security specialists are invaluable in assuring security requirements are effectively and completely addressed within applications. But it’s also true that today’s applications are far too complex for any one individual – or even a group – to comprehensively assess the security of an application. With programs scaling to the hundreds of thousands of lines of code, automated assessments are vital to your application security efforts.
Static analysis techniques, which until recently have proven impractical to apply to large scale coding projects, have come to the fore as a cost-effective and efficient way to scan even very large projects. Some static analysis software packages come tightly integrated with common development environments and build processes. They determine complete data and control flow information for programs and apply tests and checks from among thousands of rules contained in a secure coding knowledge base. Flagging vulnerabilities and coding errors for review and remediation, these tools provide background data on the consequences of vulnerabilities and offer guidance on how they can be corrected. In addition to providing hands-on vulnerability detection capabilities, some static analysis software also support high-level reporting and analysis facilities that enable careful monitoring of application security metrics.
Expert Guidance
Application security can be greatly simplified with guidance and advice from a skilled practitioner. A host of companies provide a variety of consultation services to organizations seeking to enhance their application security posture. For organizations just getting started, consulting engagements center around awareness training for developers and others supporting application development, process assessments and training in secure coding techniques can be particularly beneficial.
On an individual level, the CLASP Reference Guide is freely available to individuals tasked with enhancing security in their organization. There are also a number of books available, including Building Secure Software (Addison-Wesley, 2001) by John Viega and Gary McGraw. Their efforts have been joined by a number of other publications and papers as more members of the development and security communities begin to focus attention on the issue of software security.
The Bottom Line
According to research conducted by Gartner, more than 70 percent of all attacks are directed at applications. Experience reveals that many of us are not adequately prepared to repel those assaults – leaving our most critical IT assets at risk. It’s time to shift our attention from existing threat models and protection techniques to address these emerging software security concerns. Integrating security into the development life cycle -- both for new projects and to address vulnerabilities in updates to existing systems -- is a crucial requirement that can be eased by the adoption of clearly defined process changes, the use of automation for testing and verification purposes, and a helping hand to get started.
Go Back
|
