Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

3/27/2013
09:46 PM
50%
50%

Too Scared To Scan

Fear of business disruption and downtime often leaves enterprises hesitant to scan the critical applications that hackers are most likely to target in their quest for exploitable vulnerabilities

When it comes to detecting vulnerabilities in mission-critical applications, security professionals often find themselves in a bind. These are usually the applications that the enterprise can least afford to suffer a hack. But at the same time, they are also the applications whose owners are most likely to balk at security testing or scanning probes while they're live. These opponents to vulnerability scans on production applications point to the near-infinitesimal tolerance for downtime or disruption as reason enough to leave well enough alone. But according to security professionals, someone will eventually find those vulnerabilities and if the organization doesn't do it first odds are it is the bad guys who will ferret out the flaws.

"Scanning production applications is a challenging proposition, as availability and data integrity are paramount for organizations," says Wolfgang Kandek, CTO of Qualys. "However, security has become as important as availability, and anyway, attackers are doing their own scanning to map out the assets of the organizations, whether we like it or not."

The fact is that organizations can't fix what they don't know about, and when it comes to many of their most important production applications, many enterprises just don't have the visibility to discover potentially disastrous flaws.

[How can you start instituting a secure software development lifecycle? See 10 Commandments Of Application Security.]

"If you're not scanning production systems for vulnerabilities, you're almost guaranteed to leave some risk to your most critical assets undiscovered," says Tim Erlin, director of IT security and risk strategy for nCircle. "There is no way to manage and mitigate undiscovered risk. The trend is definitely towards more frequent scanning, but there's no doubt that there are multi-billion dollar companies out there that don't have a consistent scanning program."

Part of the pushback that occurs around scanning running applications is that those organizations with a strong focus on application security have tended to throw their resources at the front-end of the application lifecycle, says John Weinschenk, CEO of Cenzic. While that may be the most cost-effective method of addressing application security, the truth is that it doesn't address the realities of applications running in a production environment

"When you look at an enterprise, traditionally how they have handled application security has been focused at the pre-production level," he says. "But with every company that's been hacked that you've seen in the paper recently, its always the production applications that got hacked."

What's more, it doesn't address the dynamic nature of the vulnerability landscape. "Even though your development team might have given you an application that has no vulnerabilities that are known as of today, it doesn't mean a week from now that that application is still secure," Weinschenk says.

However, security professionals shouldn't sugar coat the potential risks of scanning production applications. Downtime worries aren't completely unfounded.

"You can crash it, you can take it down, you can corrupt the database," Weinschenk says. "You can do a lot of bad things to it, which, by the way, is no different than what a hacker can do to you in real life."

In particular, security organizations must be "very careful" about the way they probe legacy applications, says Vinnie Liu, managing partner for Stach & Liu. Nevertheless, most organizations can greatly reduce the risks with a number of best practices. First among them is to be mindful of when tests are done, he says.

"Folks sometimes forget that if you are testing an app you need to check for specific blackout dates or windows that might occur on certain days where especially sensitive transactions occur, like end of the month payroll on an accounting system," he says. "It's an easy one to overlook because most people just focus on either during business hours or off business hours."

He also highly recommends that security practitioners do a good job of mapping out applications prior to automated testing to look for troublesome functions that might be better suited for manual tests.

"When running a tool a lot of them crawl through the application and exercise all of the functionality in it and some of the functionality might be remove or delete a profile or delete my accounts or delete my entries," Liu says. "So it is important to go through and survey the app first to get a lay of the land."

Organizations may find that the best bet is to ease their way into more comprehensive scans through lightweight discovery scans or monitoring mode.

"The best practice for continuous monitoring is to run scans as often as possible, at least at a weekly level," Kandek says. "Scans should initially be light, in a 'discovery mode' that has minimal impact on infrastructure and applications but allows for accurate enumeration. Once machines and applications are found, scans should become comprehensive."

Additionally, says Weinschenk, organizations could look for vendors that have integrations into virtual systems that would allow them to test a virtual copy of the application rather than the real systems.

"You can do a snapshot or virtual image copy of your production applications and assess that virtual copy," he says.

Weinschenk says that larger organizations may even go so far as to be "old school" about it and stand up a mirrored environment specifically to test applications regularly, a scenario that makes sense for large enterprises like financial organizations that have robust staging environment.

Regardless of how it is done, he believes that it must be done to truly secure the applications businesses depend upon.

"If companies want to stay secure, they're going to have to start testing their production apps," Weinschenk says. "There's no excuse for a company only to test in pre-preduction because this threat model is constantly moving."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
el_viejo
50%
50%
el_viejo,
User Rank: Apprentice
4/8/2013 | 4:38:07 PM
re: Too Scared To Scan
This concern appears in every type of testing that involves production systems or even busy test systems. -Layer 3 or layer 7, in-house tester or outside penetration testing service, the same concerns are raised. -Similar push-back is common for human engineering tests. -Also, this is nothing new. -

I've been doing information security for almost two decades. -One of the first battles I had to fight was gaining authorization to perform port scans against newly implemented firewalls. -In the past month I have had to defend file crawling for sensitive data against concerns for production impact.

I see this issue as part of the job description, nothing more or less.
kjhiggins
50%
50%
kjhiggins,
User Rank: Strategist
3/28/2013 | 12:46:59 PM
re: Too Scared To Scan
The concerns here about disrupting apps sounds a lot like what the ICS/SCADA world experiences when considering (or not) patching and scanning. Mission-critical theme here.

Kelly Jackson Higgins, Senior Editor, Dark Reading
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "He's too shy to invite me out face to face!"
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16649
PUBLISHED: 2019-09-21
On Supermicro H11, H12, M11, X9, X10, and X11 products, a combination of encryption and authentication problems in the virtual media service allows capture of BMC credentials and data transferred over virtual media devices. Attackers can use captured credentials to connect virtual USB devices to the...
CVE-2019-16650
PUBLISHED: 2019-09-21
On Supermicro X10 and X11 products, a client's access privileges may be transferred to a different client that later has the same socket file descriptor number. In opportunistic circumstances, an attacker can simply connect to the virtual media service, and then connect virtual USB devices to the se...
CVE-2019-15138
PUBLISHED: 2019-09-20
The html-pdf package 2.2.0 for Node.js has an arbitrary file read vulnerability via an HTML file that uses XMLHttpRequest to access a file:/// URL.
CVE-2019-6145
PUBLISHED: 2019-09-20
Forcepoint VPN Client for Windows versions lower than 6.6.1 have an unquoted search path vulnerability. This enables local privilege escalation to SYSTEM user. By default, only local administrators can write executables to the vulnerable directories. Forcepoint thanks Peleg Hadar of SafeBreach Labs ...
CVE-2019-6649
PUBLISHED: 2019-09-20
F5 BIG-IP 15.0.0, 14.1.0-14.1.0.6, 14.0.0-14.0.0.5, 13.0.0-13.1.1.5, 12.1.0-12.1.4.1, 11.6.0-11.6.4, and 11.5.1-11.5.9 and Enterprise Manager 3.1.1 may expose sensitive information and allow the system configuration to be modified when using non-default ConfigSync settings.