Endpoint
5/29/2013
12:53 PM
Tim Rohrbaugh
Tim Rohrbaugh
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Fact Check: Endpoints Are The New Perimeter

Have endpoints been a perimeter and, if so, what should you do?

Some security professionals are stating that "endpoints are the new perimeter." If true, this statement is of manifold complexity and importance -- from a security design, control, and analysis perspective.

Are endpoints the "new" perimeter? "New" was probably used for emphasis (not meant literally) because actually nothing has changed recently to command the use of this adjective. "New" because someone just noticed this? Maybe, but I suspect that many others noticed this long ago, too.

When did the endpoints start acting as "perimeter" devices, then? Well, let's cover what is meant by "perimeter" first. With respect to context, the term is used in information security vernacular to denote a device connected to the Internet (or unknown external systems) with limited filtering or controls between. This "perimeter" device is then understood to be a gate or wall that separates the internal trusted devices from the -– bad -- scary world of the unknown. Depending on your point of view, this virtual land of baddies is comprised of Chinese (replace with any foreign country du jour that wants your stuff), cybermilitary, foreign, and domestic fraudsters, law bending competitors, malicious activists, foreign spy agencies ... so, when did the endpoint become a perimeter? Long ago, my concerned friend.

Specifically, endpoints became perimeters when a young, enterprising developer decided to use a standard application layer protocol for a purpose it was not specified for -- called overloading, e.g. in 1996 when Mudge created NetCat (I know Hobbit is listed as the author today ...) or, in more recent history, when HTTP was used to support remote desktop control, or the thousands of other examples that are right on the tip of your tongue. The problem was that all this time, stateful perimeter devices passed protocols and ports connections directly to endpoints without requiring only specified functionality. Without these, so-called perimeter devices being application-aware, any device that could request DNS resolution (for instance) from the outside network could be remotely controlled, if software (yes, malicious in this case) was aware of the application protocol's non-standard implementation -- this is one backup way that BOTS are controlled today.

So the war has been going on for a very long time under many other labels. In essence, when stateful firewalls won out over application firewalls, the doors opened for software developers to figure out how to get unexpected functionality to work through standard stateful firewalls. Originally you had to run specialized software on the endpoints to take advantage of this unexpected functionality, but shortly thereafter that was not the case, as it was considered embedded functionality. Those "trusted" endpoints on your network are actually connected to the outside, directly, in many cases. And more importantly, you have general staff who are maintaining your perimeter controls.

Would you allow a general business user to manage your firewalls? Of course not, but you are, in essence. As expected, security pros complain about employees being the weakest link. That's because, in many cases, we have general employees a mouse click away from allowing external access to your network. That's a lot of pressure for people who do not see risk and consequence (and the need for control) in the same way that you do, as a security professional.

What can you do about this?

• Use application-aware boundary devices for filtering traffic.

• Re-evaluate your network designs by creating trust zones with application-aware boundaries around your endpoints (workstations, support servers, development/test systems, etc.).

• Use sandboxing technologies on the endpoints to limit access to the real desktop environment.

• Limit entitlements or users and/or applications on the endpoint that can establish external connections.

• Change the way you analyze internal traffic, based on behavior of the endpoint, to factor in that the device is guilty (a threat) until proved innocent (trusted).

Tim Rohrbaugh VP Information Security, Intersections Inc. Tim Rohrbaugh is an information security practitioner who used military (comsec) experience to transition, in the mid 90's, to supporting Government Information Assurance (IA) projects. While splitting time between penetration testing and teaching at DISA, Mr. Rohrbaugh ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: LOL.
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6213
Published: 2014-04-19
Unspecified vulnerability in Virtual User Generator in HP LoadRunner before 11.52 Patch 1 allows remote attackers to execute arbitrary code via unknown vectors, aka ZDI-CAN-1833.

CVE-2013-6214
Published: 2014-04-19
Unspecified vulnerability in the Integration Service in HP Universal Configuration Management Database 9.05, 10.01, and 10.10 allows remote authenticated users to obtain sensitive information via unknown vectors, aka ZDI-CAN-2042.

CVE-2012-0871
Published: 2014-04-18
The session_link_x11_socket function in login/logind-session.c in systemd-logind in systemd, possibly 37 and earlier, allows local users to create or overwrite arbitrary files via a symlink attack on the X11 user directory in /run/user/.

CVE-2012-6646
Published: 2014-04-18
F-Secure Anti-Virus, Safe Anywhere, and PSB Workstation Security before 11500 for Mac OS X allows local users to disable the Mac OS X firewall via unspecified vectors.

CVE-2013-4279
Published: 2014-04-18
imapsync 1.564 and earlier performs a release check by default, which sends sensitive information (imapsync, operating system, and Perl version) to the developer's site.

Best of the Web