Talk to members of the Open Web Application Security Project (OWASP) and all will agree that app security is half a decade behind where it should be, especially at the government level. For examples of why that is, read Jeremiah Grossman's CSOonline column Web Application Security Today - Are We All Insane?
The organization routinely holds events designed to turn the trend around, including the 2009 OWASP Application Security Conference (AppSec DC) in the nation's capital Nov. 10-13. In advance of the conference, CSOonline touched base with OWASP member Matt Fisher, CEO and AppSec contractor at Piscis Security, about some of the key problems with app security today and six ways to turn things around. We begin with some questions and answers on the current state of affairs, then move to the six steps.
See also: How to Evaluate (and Use) Web Application Security Scanners
CSO: Where are organizations most out of sync in terms of how they use Web 2.0 apps and what the greatest security risks are as a result?Matt Fisher: Well, the term "web 2.0" is a bit like "cloud computing." One of the challenges there is defining it. "Web 2.0" can refer to the programming technologies and certainly the increase in browser plug-ins and client-side techs used for rich internet apps has seen their share of vulnerabilities. It can also refer to collaboration and awareness applications such as internal wikis and blogs. The risk there -- particularly on a wiki -- is that you don't have any control over the content being supplied. If that wiki is open to the entire organization then you're subject to anyone in your organization posting confidential or inappropriate content. Now, if by "web 2.0" one means social networking applications, then the risk goes up tremendously. They make good marketing platforms in that they're opt-in, and let you generate direct impressions without the cost of an e-mail campaign, and they can even be used for inbound information gathering. It's important to realize though that many of these applications have a long history of insecurity and are subject to worms and worse, all of which have the potential to damage your online brand.
Some OWASP members have described the government's app security as being about half a decade behind where it should be. Talk about why it's important for the Feds in particular to be more on top of their Web 2.0 security, in terms of its unique risks, compared to the private sector.Fisher: I think one of the most important areas to understand is that messages from the government have to be trusted, and that just because a novel Web application becomes trendy doesn't necessarily mean it's an appropriate medium for all government use. From a cybersecurity perspective, the completely off-hosted nature of these apps present a real challenge, too. They're being used to communicate department or agency information, yet there's no ability to apply your normal security process to them; you have no independent validation, can't perform a test and evaluation and have no artifacts or documentation to judge their security by. You control absolutely no aspect of the system other than your password, and frankly you don't even know if that password is being stored properly. You don't house the datacenter and have absolutely no control over the operating system security, the application security, the network defense, you can't pull an incident response on them, you can't perform any forensics. There is zero control.
See also: Application Security: The Turning Point?
Of course, theoretically the risk is very low because it's all public communication anyhow. I recently read an analysis of the subject and at one point when discussing risk it said something to the effect that integrity mattered less because it was a public system, but I don't quite agree with that. If you're using one of these sites to communicate as the United States Government, then the integrity of those messages is paramount. It's completely feasible that an adversary could find a vulnerability in one of these applications, and wait until an opportune time to use it for a misinformation or psyops campaign. Imagine all the people getting regular messages from various agencies to their cell phone. Now imagine all of them suddenly becoming subtly bogus during a national disaster.
See also: How to Create an Effective Application Security Program
Let's link this back to the private sector. One thing that comes to mind is that while government security holes can have a negative impact on private enterprise, the reverse can also be the case. Give one or two examples of this in the Web 2.0 universe.Fisher: The government has a huge contracting industry supporting it that is often very interwoven with the departments and agencies they are supporting and there a many historical cases of breaches in a contractor security exposing their customer to risk. Certainly this can exist in the Web 2.0 universe as well as outside it.
See also: Why Pen Testing Is Central to Pennsylvania's App Security
Now that we've outlined the problems, give five or more examples of steps the public and private sectors can take to improve app security.Fisher: Here are six:
1. Build a community. Large enterprises like the Federal government are particularly prone to the silo effect; a simple intranet site that's well managed can work wonders to leverage the expertise throughout an entire Department.
2. Spread the expertise. Right now the majority of what application security knowledge exists within security groups. This is a good start but ultimately the programs build and fix the applications; staff them with experts, too.
3. Think beyond tools. While tools can automate certain assessment tasks, realize that they only assist with a portion of your assessments. Even then, assessments are just one portion of an assurance program.
4. Provide guidance. Developers want to build secure, compliant software; they just don't always know how. Make standards, requirements and reference models available to your programs.
5. Don't wait to test. Late-cycle testing under release pressure is stressful on the program and testers alike. Start testing earlier in the cycles and involve your assessment team in the scheduling.
6. Zoom-in your continuous monitoring. A "minor" application change can fly through change control but create huge vulnerabilities. Scrutinize changes to applications carefully, particularly Internet-facing or other high-risk systems.
This story, "Six Steps to Pull App Security Back to the Future" was originally published by CSO.