In my last blog I discussed why web application inventory knowledge is so powerful. So I’m following that with what happens when enterprises actually get the inventory data for the first time.

Usually the first reaction is “OMG! We have a lot of stuff.” This is especially true when the discovery process detects applications outside the well known network ranges or domain patterns. It reminds me of those reality shows where they clear out all the stuff from people’s houses and lay everything out on the lawn for a yard sale and wonder how everything fit into their house.

Then the evitable embarrassment sets in.

Do I really have every disco hit record on my front lawn for my neighbors to pick through? Yes, and your neighbors might buy them at 5 for a dollar.

Do we really have 60 websites deployed with default configurations? Yes, they were probably deployed by shadow IT folks within various business units and never taken down when the folks finished their pet projects.

Is the CMS admin interface really available on these pages? Yes, someone probably forgot to delete the links or pages before synching the site. What is interesting is that in many cases that folks may know about the application but are unaware that the functionality is accessible from a variety of web pages. This is why getting the web application details in important during discovery.

Do we really have Netscape Internet Server still running? Yes, and it is using IT resources and serving up error pages since the database server it was querying no longer exists. Most likely those are applications just fell through the cracks during an internal reorganization or a change in business unit’s focus or a skipped decommissioning project.

The most successful teams get over this embarrassment quickly and look at their discovery results as “quick win” opportunities because there are some immediate actions that can be taken to improve their security posture. Abandoned web applications and web infrastructure deployed with default configurations bloat the enterprise’s attack surface and create a completely unnecessary security risk that can be addressed fairly easily. Tackling the bloat is an opportunity to work business and IT stakeholders to shrink your application perimeter to include only the applications that deliver current business value.

Just remember that emailing this embarrassing list to various folks and saying “hey, you forgot to decommission these” does not help to build a working relationship between security, business and IT teams. Odds are you can get a more positive response from the teams if this information is presented as a way to reclaim some infrastructure resources or software licenses while also improving the security posture.

This effort also helps you narrow the answer to your original question – What should I be testing? Just because the discovery process identifies 300 web applications doesn’t mean that you’d want to test the 30 that clearly should be decommissioned. More on that next time when I discuss selecting applications for security assessments.

About Jasmine Noel

At Veracode, Jasmine’s efforts are focused around market research, content development and sales enablement efforts. Previously, Jasmine was a founding partner of Ptak/Noel, an industry analyst and marketing consulting firm. Prior to that she also served as director of systems and applications management at Hurwitz Group, and senior analyst at D.H. Brown Associates. Jasmine holds a bachelor of science from the Massachusetts Institute of Technology and a master of science from the University of Southern California.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.