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.

Vulnerabilities / Threats

3/4/2008
03:05 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Survey: Enterprises Don't Know Sensitive Data Flow

Upcoming report from The 451 Group demonstrates how little progress enterprises have made in identifying and protecting sensitive data

Most enterprises still don’t know where their sensitive data resides, and less than half of those that do know are actually enforcing its protection, according to new research to be released next month by The 451 Group.

“Seventy-five percent don’t know who their employees are talking to,” says Nick Selby, director of research operations and research director of enterprise security for The 451 Group. “But this is not an IT problem -- it’s a business problem.”

The 451 Group survey, which will be published as part of its “Mind the Data Gap” report next month, found that only 37 percent of enterprises have determined where their data physically resides in the organization. Only 26 percent have established data-sensitivity classification schemes -- such as “public,” “confidential,” and “regulated" -- to label their data, and over half of those respondents say enforcement of these data classifications is nonexistent in their organizations.

Selby says of the around 320 IT decision-makers his firm surveyed, only 22 percent of them had done any analysis on interdepartmental communication. “We are finding that they don’t know where the data is because they don’t understand how they do business... They don’t understand the processes,” he says.

Those organizations that are on track with classifying their data either do business with the government or are regulated to label their data’s sensitivity, Selby says.

And it appears enterprises are out of touch when it comes to just how data leaks in the real world, according to The 451 Group. While data leakage by email accounted for only about 0.5 percent of the incidents (there were two so far) reported to Attrition.org's database this year, some 38 percent of respondents to 451's survey said employees leaking information via email or USB device, for instance, was either somewhat or very likely. And 44 percent said employees stealing information this way was somewhat or very likely, according to the survey.

But The 451 Group says this disconnect may be more about organizations in general just not knowing their users are leaking data via email. "It is inconceivable to us that so few losses occurred by a channel like email," according to its latest blog entry.

Meanwhile, Selby says before organizations throw tools at the data leakage problem, they first need to have their senior business and IT people team up to analyze data volumes, traffic, and study which groups need to talk to which groups, etc.

— Kelly Jackson Higgins, Senior Editor, Dark Reading

  • The 451 Group

    Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    Why Cyber-Risk Is a C-Suite Issue
    Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
    DevSecOps: The Answer to the Cloud Security Skills Gap
    Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
    Attackers' Costs Increasing as Businesses Focus on Security
    Robert Lemos, Contributing Writer,  11/15/2019
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Current Issue
    Navigating the Deluge of Security Data
    In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
    Flash Poll
    Rethinking Enterprise Data Defense
    Rethinking Enterprise Data Defense
    Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2019-19071
    PUBLISHED: 2019-11-18
    A memory leak in the rsi_send_beacon() function in drivers/net/wireless/rsi/rsi_91x_mgmt.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering rsi_prepare_beacon() failures, aka CID-d563131ef23c.
    CVE-2019-19072
    PUBLISHED: 2019-11-18
    A memory leak in the predicate_parse() function in kernel/trace/trace_events_filter.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-96c5c6e6a5b6.
    CVE-2019-19073
    PUBLISHED: 2019-11-18
    Memory leaks in drivers/net/wireless/ath/ath9k/htc_hst.c in the Linux kernel through 5.3.11 allow attackers to cause a denial of service (memory consumption) by triggering wait_for_completion_timeout() failures. This affects the htc_config_pipe_credits() function, the htc_setup_complete() function, ...
    CVE-2019-19074
    PUBLISHED: 2019-11-18
    A memory leak in the ath9k_wmi_cmd() function in drivers/net/wireless/ath/ath9k/wmi.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-728c1e2a05e4.
    CVE-2019-19075
    PUBLISHED: 2019-11-18
    A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.