Enterprise Network Security

Taking only the success of ransomware for evidence, one infers that too many of our enterprise networks are flat. There is a path between every pair of nodes in the enterprise.  That is to say, the ease and latency of connecting between any two selected nodes in the network is roughly the same as any two chosen at random.  This is the default that network engineers strive for.  Too often security is not even on the list of requirements.  The result is that compromise of the credentials of one end user can, and and does, bring down the entire enterprise.  

At a minimum, mission critical applications should be isolated from fundamentally vulnerable applications like e-mail and browsing.  However, isolating users, from applications, from services, from storage is even better.   Remote access should be by end-to-end application layer encryption.

Taking the isolation strategy further, create multiple layers, for example, Internet, users, applications, services, files, and storage. Nodes on one layer can access and be accessed only by those on adjacent layers.    

Finally and best, visualize a smart switch; all users, applications, and services are connected only to that switch. Think about one cable connecting that application or service directly and only to the switch (but dedicated VLANs would be more efficient.)  Any connection between a user and an application or between an application and a service can only be through this smart switch.  Users connect to the switch via TLS and strong authentication (e.g., FIDO2 for security and convenience).

The switch uses a list of rules that describes all permitted connections between an authenticated user and an application or an application and a service.  All other possible connections are denied by default, the restrictive access control policy (see Cheswick and Bellovin), least privilege, or "zero trust."  

These strategies come at the expense of some inconvenience, administrative cost, reduced function, and an increase in latency.  However, they increase the cost of attack and resist lateral spread within the enterprise network. 

Getting from a flat network to one like the ones proposed here is not trivial.  The switch must scale to the number of users, applications, services, and traffic.  The necessary and permitted connections, that is the access rules (white list), must be identified and recorded.  Mistakes may cause temporary disruption. Fortunately there are suppliers and consultants that specialize in this.  

SolarWinds

By now most should realize that SolarWinds is a compromise on an almost unimaginable scale. It is a crisis.  While there are "indicators of compromise" there are no indicators of all compromises.  While the attackers have concentrated on gathering intelligence on only a small number of target sites, all SolarWinds customers must assume that they are compromised and that there may be multiple backdoors into their systems for which there are no ICUs.  Only a small number of enterprises, perhaps none, have sufficient control over the content of their systems to be sure that they are resistant to such backdoors.

In https://us-cert.cisa.gov/ncas/alerts/aa20-352a DHS/CISA has suggested that some enterprises under some circumstances will have to "rebuild (from scratch) hosts monitored by the SolarWinds Orion monitoring software using trusted sources."  In fact, we may have to rebuild all enterprise systems.  

President Obama's chief of staff, Rahm Emanuel, famously said in 2008, “You never want a serious crisis to go to waste. I mean, it's an opportunity to do things that you think you could not do before.”  It would be tragic, if after rebuilding our systems, we should come away as vulnerable as when we started.  

We should take Rahm's "opportunity" to introduce "zero trust," indeed zero trust on steroids.  One might well start with a Software Defined Network.  One should include mutually suspicious processes, strong authentication at all levels, and "least privilege" access control.  

Rebuilding systems in month's that took decades to evolve is a daunting task.  I am reminded of what my father taught me when I was just starting out in IT almost sixty years ago.  "Son," he said, "all hard problems in information technology have one and the same answer: one application at a time."  We can do this.  We should use the crisis to overcome the inertia that has kept us from doing what we all know we should have done a while ago.  We know what to do: all we need is the leadership to do it.  

Do not worry about the cost.  Much of what we need to do, we can do with available resources.  For example, we can implement "least privilege" with available tools.  It only requires a change in intent.  In any case, there is always enough money to do that which must be done.  

On "Ransomware"

Forty years ago, my friend and colleague, Donn Parker, suggested that "employees" would use cryptography to hide enterprise data from management.  Employees because forty years ago only one's employees could send a message to one's systems.  I laughed.  It was obvious to me that such an activity would require both "read" and "write" access to the data.  I was so young and naive that I could not foresee a world in which most of those connected to enterprise systems would be outsiders, including sophisticated criminal enterprises.  Mostly, I could not anticipate a world in which "read/write" would be the default access control rule, not only for data, but also for programs.  

We are now three years since the first "ransomware" attacks.  We are still paying.  Indeed, a popular strategy is to pay an insurance underwriter to share some of the risk.  This is a strategy that only the underwriters and the extortioners can like.  While this was an appropriate strategy to follow early, it is no substitute for resisting and mitigating the attacks as time permits.  Has three years not been enough to address these attacks?  One would be hard pressed to make that case.  

The decision to pay is a business decision.  However, the decision to accept or assign the risk, rather than resisting or mitigating the attack, that is a security decision.  It seems clear that our plans for resisting and mitigating are not adequate and that paying the extortion is simply encouraging more attacks.  

By now every enterprise should have a plan to resist and mitigate, on a timely basis, any such attack.  If an enterprise pays a ransom, then, by definition its plan to resist and mitigate has failed.  As always an efficient plan for resisting attacks will employ layered defense.  It will include strong authentication, "least privilege" access control, and a structured network or end-to-end application layer encryption.  The measures for mitigating will include early detection, safe backup, and timely recovery of mission critical applications.  "Safe backup" will include at least three copies of all critical data, two of which are hidden from all users and at least one of which is off-site.  "Timely recovery" will include the ability to restore, not simply a file or two, but all corrupted data and critical applications within hours to days.  (While some enterprises already meat the three copy requirement, few have the capability to recover access to large quantities of data in hours to days, rather than days to weeks.)

One last observation.  If there is ransomware on your system, network, or enterprise, you have first been breached.  Hiding your data from you to extort money, is only one of the bad things that can result from the breach.  If one is vulnerable to extortion attacks, one is also vulnerable to industrial espionage, sabotage, credential and identity theft, account takeover and more.  The same measures that resist and mitigate ransomware resist and mitigate all of these other risks.

Ransomware attacks will persist as long as any significant number of victims choose to pay the ransom, as long as the value of a successful attack is greater than its cost.  The implication is that to resist attack one must increase its cost, not simply marginally but perhaps by as much as an order of magnitude.  Failure to do so is at least negligent, probably reckless.  Do, and protect, your job.