Endpoint
5/29/2013
12:53 PM
Tim Rohrbaugh
Tim Rohrbaugh
Commentary
Connect Directly
RSS
E-Mail
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
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.