The Frugal Networker

Pete Kofod, December 22, 2015

Juniper Networks, a leading networking equipment vendor, announced on December 17, 2015 that they had discovered “unauthorized code” in their ScreenOS software.

ScreenOS is the operating system used to run their widely deployed firewall and VPN equipment.   The software appears to have been surreptitiously inserted, granting attackers full access to the firewall and the ability to read encrypted traffic.

To make matters worse, it appears this intentional “back door” has been a part of the ScreenOS since 2012.  Given how much sensitive traffic is protected by Juniper equipment, the consequences will likely prove to be disastrous.

Juniper is the firewall vendor of choice for the Unites States Department of Defense as well as for the banking sector.    Consequently, this vulnerability impacts virtually every government agency, Fortune 100 Company as well as the broad technology sector including social media firms and their customers.  In other words, everybody is impacted.

While Juniper and their customers go about analyzing the extent of condition and remediation, we should also consider this to be a teaching moment and an opportunity to review our assumptions about how we secure systems.

Defense In Depth is Not Enough

Most IT professionals, and certainly all security professionals, are familiar with the concept of Defense In Depth.  The principle states that security functions should be layered, forcing adversaries to successfully compromise multiple layers before successfully reaching a network’s “inner sanctum.”

While this is certainly a worthy security guideline, there are good reasons to believe it may not fully meet its intended mark.  Defense in Depth historically is a network as opposed to application concept.  Simply, it is classic network security involving access lists on border routers, packet inspection by firewalls and restrictive routing policies inside the perimeter.

Unfortunately we have seen that many applications do not include detailed, multi-layered application security, choosing instead to rely on external resources (“the security team”) to save them, except the point and mandate of Defense in Depth is that each layer should include relevant and effective security.

This trend has only become more pronounced as application development has converged around web services.  Vulnerability exploitation has followed the trend and moved “up the stack.” This makes the security engineer’s responsibility far more challenging as applications, including exploits and attacks, are moving communications to HTTPS.

Defensive technologies such as Web Application Firewalls have stepped into the gap in an attempt to mitigate such attacks, but clearly they are not always successful and should not be considered the sole or even primary remedy.  Security is everybody’s responsibility, especially application developers and owners.   In addition to Defense in Depth, technologists should consider adopting cell structure approach to security.

Importance of the Cell Structure approach to Security

Cell Structure Security is the idea that the impact of system compromise can be sufficiently mitigated regardless of which system is affected.

The term traces back to how clandestine resistance groups organize themselves.  In a resistance movement organized in a cell structure if a member of a cell is captured and compelled to spill the beans, the compromise does not go beyond the individual or, at worse, the members of the cell.

To be clear, Cell Structure Security does not ask the question of whether a system can be compromised, it assumes compromise can and will occur at any level and therefore focuses on limiting the damage post-failure.

In a world of directory services and central authentication, this may seem like a tall order but analyzing the feasibility of implementing such an architecture is a worthwhile exercise nonetheless.

In the context of the current mess, it is all but certain that organizations have seen elevated credentials traverse their Juniper VPN connections completely unprotected.  The extent of condition for Juniper’s customers is still largely unknown but it should be assumed that the impact reaches far beyond just patching the Juniper systems.  In fact, the skunk may  well still be inside the walls as internal systems are likely to have been targeted based on the attackers’ reconnaissance of compromised VPN traffic.  The collapse of a single system has compromised the entire enterprise.

Premise is NOT inherently more secure than public cloud

Security remains a persistent concern for organizations considering the public cloud as a software and infrastructure platform.  Whether restricted by cultural or regulatory considerations, events like the Juniper incident should force technology managers to assess whether premise-based systems offer more effective security.

Worries have understandably been fueled by well-publicized security breaches of cloud application vendors, but even a cursory review shows lax software and system design were more often than not to blame as opposed to inherent structural flaws of the cloud.

The truth is that the public cloud, in the hands of a responsible and security conscious team should be seen as an asset that can strengthen, as opposed to weaken, system security.  Top cloud service providers offer rich security functionality, but it is up to the software vendor and client to avail themselves of it.

An interesting exercise for technology leaders to undertake is to consider the architectural differences between premise and cloud-based systems.  Odds are that if they are both well-designed, the differences are not going to be significant and the public cloud may in fact offer security features such as 2-factor authentication and web application firewalls at a fraction of the cost of premise-based solutions.

Technology teams should also challenge themselves to answer the following question:  “If we were to move all systems to the public cloud, how would we do it in a manner that is consistent with our security objectives?”  After doing that, the team should compare the move with maintaining their existing premise-based architecture.

If the team finds itself implementing security measures in the cloud, which have not been currently implemented on premise, the team should ask why that is the case.

Conclusion

While the full impact of Juniper’s security lapse will not be known for some time, it should serve as an urgent opportunity for technology teams to question fundamental security assumptions, not just vendor selection.  What happened to Juniper can happen to anybody, vendor and customer alike.  IT leaders need to spend more time guiding their teams in evaluating consequences of security failures.

While vendors tend to define problem narratives in terms of known solutions, customers should not confine themselves to following that path.

About Pete Kofod

Pete Kofod has over twenty years of technical and leadership experience in Information Technology, including the development of secure hosted services for the transportation industry as well as designing and managing networks in the utility and defense sectors. Pete is Principal of Raleigh-based Datasages Consulting Group LLC, a firm he founded in 2008 that is dedicated to providing enterprise management services to industrial and transportation customers. Pete is often called upon to lend expertise to large-scale transportation projects. He has been a material contributor to the implementation of Positive Train Control in the United States, particularly as it applies to security and availability in a hosted environment.  Pete is also cofounder of The Sixth Flag, Inc. He can be reached at pete@thesixthflag.com