I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 2 of 5 so please be sure to read part 1.
Penetration Testing
Like most application security programs, ours was started by 2 of the team members who had some understanding of the vulnerability space in applications (mostly web based) and knew how to test for them. In a company with a seemingly unlimited number of custom web applications the target space was wide and varied which provided a vast playground for exploration and learning. Over time, the value of our hacking away at these web properties coupled with a few juicy findings quickly became apparent to the leadership and we were asked to work on expanding this capability to the rest of the team while maintaining the high level of thoroughness, accuracy, and professionalism our internal customers had grown accustomed to.
We were faced with the unique challenge of defining and documenting the vulnerability space, provide documented examples of how to identify and exploit the vulnerabilities, provide in person training to explore the complexities of application architectures and the interconnectedness of various components, and provide the development background necessary to work with developers to resolve the issues. Fortunately for us, the Open Web Application Security Project (OWASP) had already published some early versions of the OWASP Testing Guide and the OWASP Development Guide. These two documents provided the written documentation necessary to begin familiarizing the team with the general concepts and jargon associated with web application security. With the help of the OWASP WebGoat tool, we were able to provide a platform on which the engineers to practice what they were learning in the documents. We also conducted some additional internal training which took and in depth look at the vulnerabilities which were most common across our specific platforms and explored the best ways to address these issues in code. After a few years of regular training and refinement of the methodology has yielded a very efficient, accurate, and repeatable security testing service. If I had to go back and do it again, I really wouldn’t change anything. The resources obtained through the OWASP organization served us well and the existing internal knowledge was sufficient to bring the rest of the team up to speed.
I also wanted to address the issue of automated scanning. We did indeed purchase a solution which we worked tirelessly to implement and customize for our needs only to find that our manual approach with a couple open source tools was performing much better than the automated solution. This was partially due to the application we were testing, we had some particularly unique extremes in size of the application to be tested, and the automated tools simply didn’t complete scans in an amount of time that we found acceptable. If I had to do it again, I would explore some more varied options for automated testing that could be better fit for the environment. I realize the importance of an automated solution to validate applications which do have strong security requirements, but that do require some level of security assurance.
Even though there have already been some great posts (Rafal Los, Gunter Ollmann, RSnake, John Steven…and again John Steven) I felt like I wanted to offer my commentary and hopefully convince some of you to attend the next OWASP event close to you. Quick disclaimer: I helped Doug, Rex, Mark, Kate and the rest of the volunteers at the conference, so I might be a little bias.
First – if you’re going to host a conference in DC, there’s really no better venue than the DC Convention Center. This is really a top notch venue in the center of DC that is built for conferences. It’s metro accessible and the conference services (food, beverages, A/V, wireless, etc) are top notch. I’m not saying the venue makes or breaks the con, but it helps.
The speakers, technical content of the presentations, and variety of topics exceeded that of much more expensive conferences I’ve attended. Joe Jarzombek kicked things off with the keynote, David Byrne and Charles Henderson can’t filter the stupid, Jon Rose and Tom Leavey brought the drinking game with a chance of 0-day, Jeff Williams tackled the insider threat, Kevin Johnson and Tom Eston think our friends want to eat our brains, Josh Abraham brought synergy to our pen-testing tools, RSnake gave security experts happy hour chatter for the next year with the 10 least-likely and most dangerous people on the web, John Steven condensed 6 hrs of Threat Modeling training into a 45 minute talk (good thing we had him scheduled at the end of the day), and Chris Weber dazzled with unicode. Not to be outdone, the OWASP projects were equally represented with Pravir Chandra on OpenSAMM, Jeff Williams on ESAPI followed by Arshan Dabirsiaghi on the ESAPI WAF, Sebastien Deleersnyder and Fabio Cerullo brought the OWASP tools together to deploy web applications, Matt Tesauro did his thing with the Live CD, Dr. Boaz Gelbord touched on security spending, and of course, who could forget Dave Wichers at the OWASP Top 10 2010 RC1! The conference also features 2 panels, the Federal CISO panel with Ray Letteer (USMC), Timothy Ruland (US Census), Richard Smith (TSA), and lead by Matt Fisher. The SDLC Panel features Michael Craigue (Dell), Dan Cornell (Denim), Dennis Hurst (HP), Joey Peloquin (FishNet), David Rook (Realex), Keith Turpin (Boeing), and lead by Pravir Chandra. The conference also featured a CTF running the new OWASP CTF project and hosted by Martin Knobloch.
For those of us who have been in the security industry for a few years, these conferences are a great chance to catch up with old friends and make new acquaintances. It was great to see familiar faces like Tom Brennan, @grecs, Ken Van Wyk, Matt Fisher, Dinis Cruz, Jon Rose, John Steven, Lee Anne Hart, Gracie Daniel, Jon McCarty, Jeremy Long, Rob Fuller, Jack Mannino, Rex Booth, Mark Bristow, Doug Wilson and others. At the same time, it was great to make new contacts like Josh Feinblum, Pravir Chandra, Robert Hansen, Matt Tesauro, Arshan Dabirsiaghi, Rafal Los, Jeff Williams, and hell, even the great Dan Kaminski made an appearance!
Just like any good conference, the awards and closing remarks held on the last day were full of thanks, toys, flying vendor squishy balls, foam rockets (courtesy of Tom Brennan), cheers, and clapping. It was truely a great way to wrap up a top notch con!
Finally, and although it’s been done many times already, I want to take a second to recognize all those OWASPers and DCers that came together to make this event what it was. I’m really copying this list verbatim from the last page of the conference booklet:
Rex Booth, Mark Bristow, Doug Wilson, and Kate Hartmann who provided the leadership without which this conference wouldn’t have come together.
The OWASP Board – Jeff Williams, Dinis Cruz, Dave Wichers, Tom Brennan, and Sebastien Deleersnyder who gave us “carte blanche” and trusted us to get this conference done.
The lead volunteers Barry Austin, Angel Contreras, Josh Feinblum, Lee Anne Hart, Martin Knobloch, Jeremy Long, Jon Rose, David Sachdev, Mike Smith, and myself.
The red shirt people of which there are way too many to name…THANK YOU!
And all those who spoke at or attended the conference!
So if you get the chance to attend a future OWASP event, or if you haven’t checked out your local chapter, hopefully this blog post and the others I mentioned in the first paragraph will shed the spotlight on the OWASP organization and how WE work to improve application security worldwide.
These days, it seems like most companies have a standard for everything…
Password standard – to make sure that we don’t simply leave the keys to the front door under the welcome mat.
Acceptable use standard – to make sure that employees aren’t playing WoW all day or hosting warez on the company servers.
(*)^11 standard – if you want to be PCI/SOX/HIPAA/* compliant.
Standards are meant to define what is acceptable or prohibited in accordance with company rules. Beyond achieving industry/legal compliance and when done right, these standards not only help employees determine right from wrong, they allow the company to operate knowing that everyone is on the same page.
Unfortunately, most organizations either overlook product/software development standards (or coding standards) or do such a poor job at defining the expectations that the development staff are left to code according to what they know best, or what they’ve done at previous employers. For seasoned and experienced developers, this might not seem like a terrible thing, so I’m going to illustrate with an example.
Joe is developing a login user interface for the next big product at the XCompany. This interface will be displayed to users visiting the application using a web browser. Being a seasoned developer, Joe implements the password portion of the login form using the HTML attribute type=”password”.
Mark is developing the iPhone application which will enable mobile users to connect to the same application that Joe is working on. Being an iPhone user himself, Mark thinks that the way the iPhone OS handles password masking is a pain and often results in failed login attempts. Mark then talks with the product manager and together they decide that instead of masking the password according to the iPhone OS standards, they’re going to display the full text of the password field until the user leaves the password field or after 3 seconds have passed without new input from the keyboard.
Jake is developing the Android application for the same product as Mark and Joe. Because Jake is paranoid and a hacker by night, he decides that the Android standard for handling passwords is too insecure and decides to totally mask the password field. Note: Android default behavior is to display the last letter typed in the password field for 2 seconds before masking.
While Mark’s approach might be acceptable and justified from a usability standpoint, and Jake’s approach might be acceptable from a security standpoint, we now have an issue where products from the same company are different in the way they implement the same functionality.
To make matters worse, without software development standards junior developers with little prior experience might end up introducing some major security vulnerabilities into the corporate applications. Lets explore another example.
Joe, Mark, and Jake are all senior developers with years of experience under their belts. In the past, their applications have been torn apart by hackers leveraging input based security flaws. As such, they’ve learned that all input must be validated prior to being consumed by the application.
Martin is the latest hire on the development team. He’s right out of college and this is his first real software development job. Eager to please, he takes on the responsibility of implementing the Search feature in the application. Bill, the project manager, agrees since the task is rather simple, all Martin will have to do is invoke the well documented search appliance API which then searches the back-end database for the results and display them back to the user. Martin quickly implements the search API and not knowing any better, doesn’t escape the user provided inputs before sending them off to the search API – now we’ve got an SQL injection vulnerability introduced into the system. (security folks, humor me, assume the API doesn’t escape input either).
While the first example seems rather benign, end users might interpret these differences as a failure to do proper quality control – which might be disastrous to the brand image if we’re talking about a major financial application. The second example leaves no room for interpretation, the lack of guidance for a new developer to lean on has introduced an avenue for attackers to steal your customers’ information or adversely impact the application by modifying or deleting critical information from the database.
If you don’t have a software development/coding standard in your organization, or if you feel that the one you have now is inadequate, here are some resources to get you moving in the right direction:
Disclosure standards and why they’re important (…and ReportSecurityFlaws.com) from HolisticInfoSec
I’m certainly a huge proponent of responsible disclosure, but I feel like I’m an even bigger proponent of good, no, SUPERIOR customer service. The moment you put a product out there that you’re charging people money for, you’re not only responsible for support requests stemming from this product, but you’re also responsible for ensuring that this product does not introduce adverse functionality for those who use it. That being said, the meat of this article lies in the announcement of ReportSecurityFlaws.com! While it seems like Ira and Russ are just getting this project off the ground, it certainly seems like this project can easily gain some legs.
PCI, Compliance, and Security from UncommonSenseSecurity
This is one of my favorite blog posts ever. I’m going to print it out and hand it to every single person who works with or around PCI. If you’re on Twitter, you’ve witnessed the back and forth(s), sometimes at nauseam. The reality of the situation is that both sides are right! Using standards, of any sorts, as the high stick for your security posture is bad. For the simple reason that each and every system, application, and infrastructure is different – simply applying a blanket set of requirements will inevitably leave some holes exposed. Security professionals should be able to take these standards and use them a crutch to convince executives and build an effective security program. Shouldn’t be hard, Mr. Carr thought that checkboxes made his customers’ data secure.
Yahoo!, Paypal, Google, Equifax, AOL, Verisign, Acxiom, Citi, Privo, Wave Systems Pilot Open Identity for Open Government from InformationCard.net
In case you missed the announcement this week, the U.S. Center for Information Technology (CIT), the National Institutes of Health (NIH), and the U.S. Department of Health and Human Services (HHS) partnered with the OpenID Foundation (OIDF) and the Information Card Foundation (ICF) to add support for OpenID and Information Card technologies. This partnership follows President Obama’s memorandum instructing Government websites to allow citizens to participate in said websites without having to create additional usernames and passwords. I would specifically like to highlight AOL’s participation in this initiative which has been spearheaded by my colleague George Fletcher (http://practicalid.blogspot.com/). Congrats George, all that hard work and meetings has paid off big!
Good vs. Good Enough from PreachSecurity
This is a really interesting (and simple) approach to scoping. Lets say your site is a mildly interactive blog, like a generic Honda Civic with the bare bones accessory package and a stick shift. Setting your club and locking your doors is really all you need to do, unless you’re one of those really paranoid people. On the other hand, if you drive a Ferrari with every luxury option and a laptop with $20k in cash on the passenger seat, you’re not only going to set your club and lock your doors, you’re also going to install an alarm, lo-jack, and possibly post a very large and menacing looking man to stand guard. Not only that, but if the laptop and the 20k in the passenger belong to me and you’re responsible for keeping them safe, I expect you to post 2 very large and menacing men outside your car. Here’s another great post from @rybolov with a similar tone, but focusing more on motives and opportunities – http://www.guerilla-ciso.com/archives/1312
Interview about AppSec DC with OWASPs Doug Wilson from NoVAInfoSecPortal
GREAT interview by my DC area peers @grecs and @dallendoug…but, I might be a little biased as I volunteer with Doug on the AppSec DC planning committee. The interview covers questions and answers ranging from a preview of the conference training and speaking engagements, the need for volunteers (REALLY, WE NEED VOLUNTEERS, INQUIRE WITHIN!), and who would benefit from attending the conference (spoiler alert! – EVERYONE can benefit from this conference, it’s going to be the best WebAppSec con the DC area has ever seen). Once you’ve read the interview, cruise on over to http://appsecdc.org/ and checkout the training courses and conference speaker lineup, I promise you won’t be disappointed.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 2 of 5 so please be sure to read part 1.
Even though there have already been some great posts (
These days, it seems like most companies have a standard for everything…
For those of you in the Northern Virginia and surrounding area and who are into web application security, mark you calendars for April 8th, 2009!
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin