Endpoint
5/29/2013
12:53 PM
Tim Rohrbaugh
Tim Rohrbaugh
Commentary
50%
50%

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
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-1414
Published: 2015-02-27
Integer overflow in FreeBSD before 8.4 p24, 9.x before 9.3 p10. 10.0 before p18, and 10.1 before p6 allows remote attackers to cause a denial of service (crash) via a crafted IGMP packet, which triggers an incorrect size calculation and allocation of insufficient memory.

CVE-2015-2072
Published: 2015-02-27
Multiple cross-site scripting (XSS) vulnerabilities in SAP HANA 73 (1.00.73.00.389160) and HANA Developer Edition 80 (1.00.80.00.391861) allow remote attackers to inject arbitrary web script or HTML via unspecified vectors to (1) ide/core/plugins/editor/templates/trace/hanaTraceDetailService.xsjs or...

CVE-2015-2075
Published: 2015-02-27
SAP BussinessObjects Edge 4.0 allows remote attackers to delete audit events from the auditee queue via a clearData CORBA operation, aka SAP Note 2011396.

CVE-2015-2076
Published: 2015-02-27
The Auditing service in SAP BussinessObjects Edge 4.0 allows remote attackers to obtains sensitive information by reading an audit event, aka SAP Note 2011395.

CVE-2015-2101
Published: 2015-02-27
Cross-site scripting (XSS) vulnerability in the Navigate bar in the Navigate module before 6.x-1.1 and 7.x-1.x before 7.x-1.1 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.

Dark Reading Radio
Archived Dark Reading Radio
How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.