While web applications continually evolve and adapt to new technologies, hackers evolve too. At first glance, it may seem like a never-ending cycle of hackers gaining mastery over new technologies. But a deeper look into web-application vulnerabilities shows that the root causes of these vulnerabilities have remained fairly constant over the last decade. In order to best combat evolving threats, companies need to understand the foundation of application vulnerabilities and adopt basic security best practices.
Year after year, the same web-application attack vectors are repeated as major vulnerabilities in client web applications. Attacks today are new by nature simply because they interact with new technologies. The methods used in today's common attacks, such as cross-site scripting, are similar to the worm problems of the late 1990s. The goal of both is to inject malicious code. Today it is script; 10 years ago it was a virus.
The Groundhog Day phenomenon needs to be viewed at the most basic cause level, rather than vendors constantly trying to outdo malicious hackers with new technologies. Fifteen years ago, the cause of attacks could be attributed to developers not doing proper input validation. The same is true today. What is different is that threats have shifted in priority and the consequences are now much greater. While a decade ago hackers hacked for notoriety, today the end goal is usually financial gain with the aim to illegally procure financial and personal data to meet those goals.
What can organizations do to safeguard their web applications? Companies need to take a holistic approach and involve a variety of departments throughout the entire software development life cycle (SDLC).
Despite almost daily breaches, the industry has still not learned important security lessons. Security departments have failed to communicate best practices to the developers — an organization's first line of defense in the SDLC. Security fixes, while the application is in development, are less time consuming and less costly to make. The companies that are most successful in defending their web applications make security a top priority for everyone — not just the security department.
Organizations need to make smart and deliberate choices throughout the SDLC and take the following steps that will result in a better educated staff and safer web applications.
1. Mature framework: Use an established framework. If you are a Java developer you should be building on a Struts framework. If C++ is your language of choice, use the .NET framework. These mature frameworks have already considered many of the security threats and have built-in ways to help prevent web application vulnerabilities. When you use established frameworks, you build on years of experience of all the past developers before you.
2. Education: People must understand the software they are building and how to mitigate security threats. Companies need to institute best practices throughout all levels of the organization — even at the highest levels.
3. Resource library: The developers, managers and security practitioners need a single spot where they can all draw from the same pool of information. Topics covered should include basics such as principals of designing safe software to a list of top threats faced by software applications today. The library should also list certified components used in your organization. This standardization allows a base knowledge among all employees. And when your developers are designing safer web applications, this allows more time for the security specialists to focus on major exceptions and other top priority threats where standardizations don't exist.
Who manages the resource library? The security practitioner should be in charge of the security resource library as they have the best understanding of the threats as well as the principals of security.
4. Training program: While a solid education is the basis of any successful organization, education cannot be a one-time event. Training needs to be ongoing so that the technical staff can advance their knowledge base. Examples include computer based training, seminars and workshops.
5. Metrics: A company can measure the adoption of application security standards. Developers should be rewarded or reprimanded depending on their participation in training, as well as around how religiously they find and fix security issues within their projects. Companies should note if the overall number of vulnerabilities is dropping and provide a case study on why the drop is happening. Metrics should track the performance of individual developers as well as the overall application-security process.
Where does a company begin?
If you don't have a process in place, it's most efficient to start with training. A company should establish an application security policy and practices for education throughout the entire company and then work down the list.
Even small companies who work on the bleeding edge of technology can do more to address web application security. If your applications depend on AJAX or other Web 2.0 technologies, a company needs to beef up education and training and make sure the communication channel between developers, security and QA is as open and transparent as possible.
The industry is beginning to learn the security lesson and is slowly building security into the whole process. But continued education is needed to ensure the industry stays ahead of the hackers.
Danny Allan is director of security research at Watchfire, an IBM company
Year after year, the same web-application attack vectors are repeated as major vulnerabilities in client web applications. Attacks today are new by nature simply because they interact with new technologies. The methods used in today's common attacks, such as cross-site scripting, are similar to the worm problems of the late 1990s. The goal of both is to inject malicious code. Today it is script; 10 years ago it was a virus.
The Groundhog Day phenomenon needs to be viewed at the most basic cause level, rather than vendors constantly trying to outdo malicious hackers with new technologies. Fifteen years ago, the cause of attacks could be attributed to developers not doing proper input validation. The same is true today. What is different is that threats have shifted in priority and the consequences are now much greater. While a decade ago hackers hacked for notoriety, today the end goal is usually financial gain with the aim to illegally procure financial and personal data to meet those goals.
What can organizations do to safeguard their web applications? Companies need to take a holistic approach and involve a variety of departments throughout the entire software development life cycle (SDLC).
Despite almost daily breaches, the industry has still not learned important security lessons. Security departments have failed to communicate best practices to the developers — an organization's first line of defense in the SDLC. Security fixes, while the application is in development, are less time consuming and less costly to make. The companies that are most successful in defending their web applications make security a top priority for everyone — not just the security department.
Organizations need to make smart and deliberate choices throughout the SDLC and take the following steps that will result in a better educated staff and safer web applications.
1. Mature framework: Use an established framework. If you are a Java developer you should be building on a Struts framework. If C++ is your language of choice, use the .NET framework. These mature frameworks have already considered many of the security threats and have built-in ways to help prevent web application vulnerabilities. When you use established frameworks, you build on years of experience of all the past developers before you.
2. Education: People must understand the software they are building and how to mitigate security threats. Companies need to institute best practices throughout all levels of the organization — even at the highest levels.
3. Resource library: The developers, managers and security practitioners need a single spot where they can all draw from the same pool of information. Topics covered should include basics such as principals of designing safe software to a list of top threats faced by software applications today. The library should also list certified components used in your organization. This standardization allows a base knowledge among all employees. And when your developers are designing safer web applications, this allows more time for the security specialists to focus on major exceptions and other top priority threats where standardizations don't exist.
Who manages the resource library? The security practitioner should be in charge of the security resource library as they have the best understanding of the threats as well as the principals of security.
4. Training program: While a solid education is the basis of any successful organization, education cannot be a one-time event. Training needs to be ongoing so that the technical staff can advance their knowledge base. Examples include computer based training, seminars and workshops.
5. Metrics: A company can measure the adoption of application security standards. Developers should be rewarded or reprimanded depending on their participation in training, as well as around how religiously they find and fix security issues within their projects. Companies should note if the overall number of vulnerabilities is dropping and provide a case study on why the drop is happening. Metrics should track the performance of individual developers as well as the overall application-security process.
Where does a company begin?
If you don't have a process in place, it's most efficient to start with training. A company should establish an application security policy and practices for education throughout the entire company and then work down the list.
Even small companies who work on the bleeding edge of technology can do more to address web application security. If your applications depend on AJAX or other Web 2.0 technologies, a company needs to beef up education and training and make sure the communication channel between developers, security and QA is as open and transparent as possible.
The industry is beginning to learn the security lesson and is slowly building security into the whole process. But continued education is needed to ensure the industry stays ahead of the hackers.
Danny Allan is director of security research at Watchfire, an IBM company
