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
Perimeter Inversion: Turning Digital Security Inside Out
Newest First  |  Oldest First  |  Threaded View
RobertQ007
50%
50%
RobertQ007,
User Rank: Apprentice
12/15/2015 | 4:29:15 PM
Time for the cloud-DMZ?
The concept of a dynamic cloud perimeter is very appealing when faced with mobility and hybrid cloud.  Create the cloud-DMZ once and have all access go through it regardless of where the users, enterprise apps and data lie.  Better yet if the "on-prem" components can effectively take the enterprise infrastructure off the Internet completely and the cloud-DMZ becomes the new LAN.

Unfortunately, the idea that enterprises can "extend-the-perimeter" by establishing trust with user and devices doesn't work in the new outside-in world where all users are accessing internal company data and application from the Internet.  With exploits like the recent StageFright, the reality is we can never be sure that trust, once established, has not been compromised.
hojtfredrik
50%
50%
hojtfredrik,
User Rank: Apprentice
12/10/2015 | 7:58:32 AM
Distributed networks
The future will be even more complicated. There is no one single model for applications and no more private networks. Depending upon the application you will need to communicate with clouds, data centers, devices, mobiles, IoT. etc. Roaming between different access networks with different Quality of Service. With bandwidth becoming a very limited resources with billions of new connected devices. And many devices, IoT and applications will communicate directly peer-2-peer without any cloud connection. Why should a key app to your car have to communicate with a cloud somewhere? It would only open for Man-in-the-Middle attacks, DDoS failures, etc.  as well as require unnecessary bandwidth usage.

Security can no longer be peripheral as pointed out here. It must be application, user and situation dependent. And asynchronous to provide reliable transport mechanisms. 

This all means new architectures and methods, that will vary between application types. And yet it has to be simple to develop, implement and maintain, otherwise it will not be used. An open field for innovation and startups like apptimate.io.

 


News
A Startup With NSA Roots Wants Silently Disarming Cyberattacks on the Wire to Become the Norm
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/11/2021
Edge-DRsplash-10-edge-articles
Cybersecurity: What Is Truly Essential?
Joshua Goldfarb, Director of Product Management at F5,  5/12/2021
Commentary
3 Cybersecurity Myths to Bust
Etay Maor, Sr. Director Security Strategy at Cato Networks,  5/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google Maps is taking "interactive" to a whole new level!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-21830
PUBLISHED: 2021-05-17
A heap based buffer overflow vulneraibility exists in GNU LibreDWG 0.10 via bit_calc_CRC ../../src/bits.c:2213.
CVE-2020-21832
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exists in GNU LibreDWG 0.10 via read_2004_compressed_section ../../src/decode.c:2417.
CVE-2020-21833
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exits in GNU LibreDWG 0.10 via: read_2004_section_classes ../../src/decode.c:2440.
CVE-2020-21834
PUBLISHED: 2021-05-17
A null pointer deference issue exists in GNU LibreDWG 0.10 via get_bmp ../../programs/dwgbmp.c:164.
CVE-2020-21835
PUBLISHED: 2021-05-17
A null pointer deference issue exists in GNU LibreDWG 0.10 via read_2004_compressed_section ../../src/decode.c:2337.