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.

Comments
Making the Case for a Cybersecurity Moon Shot
Newest First  |  Oldest First  |  Threaded View
drmikelloyd
50%
50%
drmikelloyd,
User Rank: Author
2/26/2019 | 7:36:41 PM
Re: A network that understands hardness
Sure - how about:

Abandon the "permitted by default" network model.  Endpoints must prove to networks that they are ready to be exposed to anything beyond their immediate neighborhood.  Moderate access requires only basic proof of hygeine, while a new Internet-facing web server (or container) must demonstrate being hardened and ready before the flood gates are opened.
adamshostack
50%
50%
adamshostack,
User Rank: Apprentice
2/26/2019 | 6:58:42 PM
Re: A network that understands hardness
I think I see where you're going -- can you rewrite it as a moonshot goal?
drmikelloyd
50%
50%
drmikelloyd,
User Rank: Author
2/25/2019 | 8:43:26 PM
Re: A network that understands hardness
Right - there is a big distinction between general purpose endpoints and special purpose "things".  Laptops get patched regularly, and have decent internal firewalls.  That said, the market for network firewalls has not gone away - it's interesting to look at reasons why. 

Laptops are great and all, but they aren't where most of the value resides.  Data centers are fragile in one way - huge uptime pressure, and an unwillingness to patch.  IoT devices are fragile in a completely different way - they lack a decent patching infrastructure, and are generally designed to a pricepoint, not about flexible response to a changing security landscape.

My response to your moonshot question comes from a point of view that "between" still matters.  Security tech is either placed on endpoints, or between them.  The endpoint security products face challenges (too many agents, not to mention endpoints that aren't built to accomodate agents - does your fridge?).  That's why there is still a large challenge space around "between" controls.  It's the old debate - shiould the network just be dumb pipes, or should it provide intelligent services and controls?

I'm suggesting a moonshot for a network that can enforce intelligent controls *between* endpoints as the way forward.  This is a moonshot because today, endpoints do not have to play along, or follow any hygeine standards, or register what kind of object they are.  We've stacked up some ways to lock down laptops, and messed around with MDM, but what about all the things that are neither?
adamshostack
50%
50%
adamshostack,
User Rank: Apprentice
2/25/2019 | 6:09:50 PM
Re: A network that understands hardness
Hi thanks Mike!

 

Is this still a problem? I was under the impression that most mainstream systems were fairly firewalled these days, but perhaps I'm thinking more of desktops and less of IoT?

 

Adam
drmikelloyd
50%
50%
drmikelloyd,
User Rank: Author
2/20/2019 | 2:39:43 PM
A network that understands hardness
Nice question, Adam.  How about a project to ensure a machine directly exposed to the Internet does not immediately succumb to all the known "background radiation" out there? 

There are a range of possible implementations (proactive vs reactive hardening).  But similar to your goal of "email payloads should never be detonated", I'm thinking "maintain a living battery of tests that must pass as basic hygeine before a machine can be exposed widely".  It's not NAC - it's more like the inverse.  NAC says you can't even access a local network unless you're "clean" to a specified level.  This project flips that, to say the level of hardening required depends on breadth of exposure to others.

The moonshot aspect of this is to teach the network (where access policy is enforced) about the quality or hardness of each endpoint.  In an IoT future, this may be essential - consumer IoT is too weak to be treated like other endpoints.
schopj
50%
50%
schopj,
User Rank: Strategist
2/19/2019 | 4:31:31 PM
Moonshot
Getting Microsoft to log at least as much as Sysmon and to start better protecting those logs so they cant be easily deleted, or if they can, can also be easily recovered.  I shouldnt have to install a third party app, or any app, just to get detailed logs monitoring process hashes and who started what from what program, or any of the other things that advanced logging applications log.  It is an MS operating system and it should log everything that is done on it, period.  


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.