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.  

Bits are Bits

 NIST Cannot quite get it right.  They have gone from encouraging the use of special characters to discouraging them and relying only on password length.  

The strength issue is not about what the user must enter in an ascii or other code but how much work it would take an exhaustive, or brute force attack to find it.  Both length and special characters are ways to increase the work of attack.  Each adds bits.

We first started to Insist upon upper and lower case and special character to get more bits in fixed length passwords.  While most of you are to young to  remember it, for years passwords were limited to 8 characters, or one fetch, for performance reasons.  While modern computers are so fast that performance is no longer an issue and modern database managers will accommodate passwords of any length, there may still be systems that limit the length of passwords.  Unfortunately, we forgot why we were insisting upon complexity.

Before the Internet, most end users had fewer than a handful of passwords, many only one.  Today many users have tens, even hundreds of passwords. (As I write this, I have 310.)  As the number of passwords grew so did bad practice.  Users chose passwords that were easy to remember and enter, and then reused those that met these tests.   

To resist this user behavior, many managers introduced rules to encourage strong passwords and resist weak or reused ones.  This solution has become the problem. Choosing passwords was already hard enough; choosing passwords that meet well intended but otherwise arbitrary rules is often too much.  Otherwise strong passwords, including those generated by a password manager, might not meet the rules.  Forcing periodic changes added insult to injury.  

Thus, NIST now recommends length.  While length adds to strength, the longer the password, the harder it is to enter, particularly without error.   The strength is measured in bits, not , but the use of the entire character set may help; in some special cases may still be required.  

All this is by way of saying choosing, remembering, and using strong passwords is not easy.  Choosing, remembering, and entering, more than a handful of passwords is not easy.  It has become a computer application.  Password managers are somewhere between popular and necessary.   

Courtney taught us that "nothing useful can be said about the security of a mechanism (including passwords) except in the context of a specific application and environment."  Writing guidance that covers all applications and environments has always been what we call a "hard problem."  Writing guidance that will stand up to changes over time is particularly hard.

A final word. Well chosen and managed passwords are resistant to brute force attacks.  Those are not the kind of attacks that we are seeing.  Rather, we are seeing social engineering followed by fraudulent replay attacks.  Passwords, of whatever strength, are fundamentally vulnerable to replay attacks.  Rather, we need strong authentication, that is, at least two kinds of evidence, at least one of which is resistant to replay.  Said another way, all strong authentication is multi-factor but not all multi-factor is strong.  

Prefer length to complexity, but allow the whole character set.  (Encourage complexity if length is otherwise restricted.)  Encourage your users to use a (cross platform?) password manager. Offer them strong authentication options.  Mandate strong authentication for employees.  Consider, indeed prefer, passkeys (https://whmurray.blogspot.com/search?q=passkeys).  Use biometrics for convenience in applications where replay is otherwise resisted. Prefer one-time passwords to mandatory periodic password change.  

Employee Resisitance to New Controls

One of the reasons that our security is as bad as it is, is the perceived resistance of employees to new, or even changed, controls.  Why is it that even enterprises that offer strong authentication to customers, still rely upon fraudulently reusable passwords, vulnerable to social engineering, for employee authentication?  Employees continue to rely upon passwords even though they are implicated in more than half of all breaches and even though msny strong authentication solutions are much more convenient than passwords.  Could it be, at least in part, that management wants to avoid the inevitable employee whining that accompanies any and every change in controls?

Its true!  Many, not to say most, employees do whine and complain over any change in controls.  Even good managers are deterred from such changes by such resistance.  The good news is that most of the resistance only lasts a day or two.  Even those who complained the earliest and loudest get over it in a day or two.  They do not continue to resist what they quickly come to see as inevitable.  

Oh its true, a few continue to complain.  Let's face it, they were not happy yesterday, they will not be happy tomorrow, their happiness is not within management's control. They are grievance collectors, Failing to do the right thing in an attempt to quiet their complaints is futile.  Get over it.  Do the right thing.  

Prefer eSIMs

The SIM (Subscriber Identity Module) is a finger nail sized integrated circuit (IC) that fits into a slot on your wireless phone.  It stores a number called the International Mobile Subscriber Identity (IMSI) and its related key.  

The IMSI is what associates your mobile phone with your telephone number and your mobile service provider.  It is "provisioned" by your service provider when you open your account and place it in your phone.  If you get a new phone all you need to do is move the SIM to the new phone in order for your number to ring on the new phone. Your number travels with the SIM.

Your phone also has a unique identifier, the International Mobile Equipment Identity, or IMEI.  When you make a call, the system sees both the SIM and the IMEI.

Your service provider also has an account number for you that they use to record all the information about your plan, your charges, payments, and balance or credits due.  This number is unique and binds you and your carrier.  It remains the same across phones, phone numbers, and SIMs.  

Many of us use our phones as evidence of our identity in systems of strong authentication (at least two kinds of evidence, at least one of which is resistant to replay).  This takes two forms.  We may have a "soft token" (e.g., Google Authenticator, Microsoft OKTA, Symantec VIP Access) on our phone. This is an app that generates a one time password every minute.  The app is synchronized with a server in the Internet.  Another app, for example for your bank account or other business application, may prompt for the OTP at logon time.  It will submit the number you supply to the server to ensure that you have the soft token.  Possession of the phone, "something you have" and can use, as one form of evidence in a system of strong authentication.

Alternatively, you may register your phone number with an application provider.  At logon time, the provider may send a OTP message (SMS) to your phone which you can copy and paste into a prompt at logon time.  Only someone receiving the text, that is can receive text at that phone number, can successfully logon to the application.  This is marginally more convenient than the soft token; it is also marginally less secure.  It depends upon the application provider having the right phone number associated with your account, and your wireless service provider having your phone number associated with your phone.  

Herein lies the limitation of this measure.  If an attacker can dupe your wireless service provider into re-assigning your number to his device, then he can receive the OTP message.  Because this attack usually involves the wireless service provider also giving the attacker a new SIM, this attack is known as "SIM swapping."  A similar attack involves duping the application provider into  changing the wireless phone number associated with your account to that of the attacker.  Both of these attacks require duping support personnel.  (See also "port-out" attacks.)

Note that support personnel are trained and motivated to be supportive.  If they think that they are talking to you, they will do whatever they are asked.  Of course, they are also trained and motivated to be sure its you but there are lots of them and their training may be spotty.

This is where the eSIM comes in.  Instead of storing the IMSI on an IC, in late model phones it can be stored in a High Security Module (HSM) on the phone.  Instead of being provisioned by support personnel at your wireless provider, it is provisioned by you either by running an app on your phone or scanning a QR code.  

The app comes from a network service provider (e.g., AT&T, Verizon, T-Mobile) or a contractor (e.g., Consumer Cellular, AARP, Mint Mobile, Nomad) with those that do.  It is to be hoped that you are a little more concerned with your identity than any of these service providers.  These contractor service providers, that do not operate their own networks, may compete on the basis of price, coverage, data plan, or a combination of these.  While some may provide a SIM card for old phones, for late model phones they use eSIMs.

In any event, if your phone suddenly stops working, you may be the victim of a SIM swap.  Contact your service provider immediately.  Do not hesitate.

Passkeys

By now you have probably heard about the "death of passwords," or at least alternatives to them.  Passkeys are one such alternative.  Apple, Google, and Microsoft  are rolling them out.  https://tinyurl.com/PasskeySupporters  They are intended for use in remote login to web based applications.  (While apps can use passkey, many are already passwordless.) PayPal, Kayak, Best Buy, eBay, GoDaddy, and Google are among those that are offering Passkeys as a preferred alternative means of user authentication. 

Passkeys resist the security problems with passwords.   They eliminate both the choice of password requirement and the forgotten password problem.  They resist brute force and replay attacks.  Social engineering (e.g., so called "phishing") attacks no longer work.  While the user may still be duped into logging on, the process that that uses does not leak reusable information. 

(However, Passkeys may still leave one vulnerable to session stealing (MitM) attacks. This is a limitation that they shares with most remote authentication methods.  Note that, unlike the reuse of passwords, MitM attacks do not include the ability to initiate sessions, only takeover sessions initiated by the legitimate user.  They also require the ability, usually by duping the user, to insert a process between the user and his target application.)

Passkeys are an application of asymmetric key cryptography.  They are an implementation of the Fast Identity Online (FIDO) standard defined by the FIDO Alliance.  

The private key is stored on a user side device, usually in an high security module (HSM) or trusted platform module (TPM)  and is used to sign a challenge (random value sent from the application side.)  The corresponding public key is stored on the application side and is used to verify the signed challenge.  Every time one chooses to sign on to an app or a web application with a passkey, one must authenticate to the device by biometric or PIN.  

Thus Passkeys offer strong authentication.  One must possess the device holding the  private key, something that one has, and the biometric, something that one is, or PIN, something one knows, required to open the device at time of use.  The exchange of the challenge and response resists replay.  

Most often, and at least in the short run, apps that implement Passkeys will  leave their use at the option of the user.  It will be offered as an option, either at enrollment time or when signing on.   If one accesses an account from multiple devices, one  may create a passkey for the account on multiple devices.  Apple plans to store keys in the cloud, as does now with passwords, so that one key can be used across multiple Apple devices sharing access to one Apple account.  

When attempting to logon to an account that expects a passkey from a device that does not already have access to a key, one may be offered a QR code to sync to a device that does have access to a (or the) key.  Both the security and the convenience are maintained.  

Indeed security and convenience are what Passkeys are about.  They make it easier to do the right thing than the wrong thing.  Smart enterprise applications will offer them as an option and smart users will choose them.  Some enterprises will mandate them.  They offer us one more opportunity to increase the cost of attack against our networks, systems, applications, and data while improving convenience.  

Note that Passkeys rely for their security in part on the device on which the private key is stored.  Thus they are often seen as limited to a single device.  However, a number of mechanisms are available to enable their safe use across devices.  These include storing the key in a "password manager" (e.g., Bitwarden) or using the network or the cloud (Apple's implementation.)

The Biden Executive Order

There is nothing like long lines at the gas pumps to get the attention of government.  This is an initiative that is long overdue.  There is a great deal to do.  Cyber is the infrastructure that we use to operate all the others, particularly to include energy and finance, and it is all too fragile and porous for the reliance that we have upon it.  

It is good to see that "zero trust" made the list.  The concept goes back to the mainframe and many of us have been actively promoting it for the internet for years.  It is important to use it both horizontally, that is system to system and service to service, and vertically, through the layers of the application.  

Zero Trust requires strong authentication (at least two kinds of evidence, at least one of which is resistant to replay) both user to system and process to process.  One cannot trust a process whose identity is not reliable.  If strong authentication is not the single most effective and efficient measure at our disposal, it is certainly among the top three.  It deserves its own mention.  

Zero trust also implies resistance to lateral compromise within the enterprise.  It should not be possible to compromise an entire enterprise simply by getting one user to click on a bait message in an e-mail or on a web-site.  In addition to resistance to fraudulent credential replay, we need structured networks.  I would like to see end-to-end application-layer encryption but, at least in the short run, I would settle for network segmentation and layering.  

I am glad that it addresses software quality.  However, the practice here is so shoddy and the contributors so many that simply saying we will address it through government purchasing power will not be enough.  Nor can we rely on training alone.  We need systems and development processes that make it much easier to do it right than to do it wrong.  

I would like to have seen the order address accountability and transparency for privileged users.  Edward Snowden should not have been able to run rampant through a network that one would have expected to be "secure."  It is ironic that the place that we are most likely to see shared credentials is among privileged users.  Wherever there are two or more privileged users per shift, we need privileged access policy and management systems.  

We cannot continue to allow just any amateur to connect anything they like to the public networks.  While it may require legislation, we must require that only mechanisms built by professionals to infrastructure standards (e.g., built for the ages, fails in an orderly and safe manner, resistant to easily anticipated misuse and abuse) can attach directly to the public networks.  As we need structure networks within the enterprise, we need structure within the Internet.  

We also need to have accountability for suppliers who distribute (malicious) code that they did not write.  This too may require legislation but a class action suit against SolarWinds would be a start.  

The Biden Executive Order is a start but only a start.  There is much to do.  Let us get on with it.

What I tell my family about protecting their identity.

 Recently a family member asked me how to respond to a solicitation for "identity protection."  The ad appealed to fear and some of the benefits were ambiguous. 

Every time we open an account or do business, we expose ourselves to fraud.  About three percent of us will be the victims of transaction (e.g., payment card) fraud but almost one percent of us will be victims of fraud so serious as to cause serious financial loss or crippling  damage to our reputations.  Therefore, I offer the following advice in the order of its importance.  

• Use strong (e.g., multi-factor) authentication wherever it is offered.  (Prefer Passkeys for a good balance of security and convenience.)
• Avoid doing business with those who do not offer it.
• Prefer purpose-built applications for financial activity.  Avoid the use of browsers.
• Prefer mobile computers to personal computers for financial activity.
• Review all account balances and activity on a timely basis (for large and active accounts, "review" equates to online and "timely" may equate to daily.)
• Sign up for "paperless" options.  (For good security these should be the default option but for reasons of "backwards compatibility," one must usually opt in.)
• Allow notifications.  (Again, this should be the default.)*
• Freeze your identity on all three credit bureaus.  (Locking and unlocking is now easy and free but all three bureaus will take every opportunity to try and sell you "identity protection" for a relatively high annual fee.  All three have had major compromises of personal data and are not reliable.)
• Use complimentary credit monitoring from AAA, American Express, or, as offered, by your bank or credit union.
• Most card issuers now permit you to "lock" your cards, using a mobile app.  Balance this with the convenience of using the card but be sure to lock the card if it is misplaced, lost, or stolen.  
• When buying online, prefer to pay with such checkout proxies as PayPal, Apple Pay, or Click to Pay.  Avoid using debit or credit cards.  However, prefer credit cards to debit cards.  
• When paying at the point of sale, prefer "contactless."  This resists the leakage of the Primary Account Number on the magnetic stripe.  Most banks now offer such cards and both Apple and Google Pay offer.
• Do not use the option permitting the merchant to retain debit or credit card information.  Checkout as a guest; avoid signing up for accounts.  
• When using debit or credit cards for the convenience of frequent purchases from a merchant (e.g., Amazon) consider the use of a one-time or one merchant token number from Privacy.com.  
• Consider insurance against financial loss and/or expenses related to identity theft.  Such insurance is not a substitute for any of the measures above, may be redundant of protections that you already enjoy (from homeowners insurance, fiduciaries, e.g., https://www.fidelity.com/security/customer-protection-guarantee ), may be expensive, and is best purchased from insurance sources (e.g. as an optional endorsement  to one's homeowners insurance).  https://tinyurl.com/FTCreportidenttiyfraud

* While I have been writing this I have received notices of three legitimate transactions.  This assures me that I will get timely notification of fraudulent ones.  

EBA Relaxes Requirements for Strong Authentication

"The European Banking Authority (EBA) has issued a new Opinion that provides the European payments industry with an EU-wide additional 15 months to comply with strong customer authentication (SCA) requirements for online ecommerce transactions."

Since there are banks that are already in compliance, the solution for consumers is to do business only with those banks.  

While there is no international law on this, there is good banking practice that is universal.  All banks have an obligation to "know their customers," and to ensure that "transactions are properly authorized."  Passwords that are vulnerable to fraudulent reuse do not meet these standards of good practice.  

In an era when most customers have e-mail, mobile computers, or both, strong authentication is not sufficiently difficult to implement to justify an extension.  This is an example of "regulatory capture."  The authority is derelict.  It is serving banks rather than customers.  Shame.  

Limitations of Biometrics

It is Blackhat/Defcon time so it should not surprise anyone that the media is full of hacks. While the hackers pretend to demonstrate that the security mechanism is useless, most of the attacks are so expensive as to be impractical.  What they really demonstrate is the limitations of the mechanism.  Regular readers of this blog know that all security mechanisms have limitations; understanding those limitations are part of our stock in trade and I write about them often.   

A recent demonstration spoofed Apple's FaceID in only "120 seconds," as though that were the only cost of attack.  They omitted the special knowledge and access.  A recent article in BankInfoSecurityNews raised alarms over the discovery of a database of fingerprint images for sale.  

First, keep in mind that biometrics are really about convenience, not security. That is why they are best used as one factor in multi-factor systems. 

Second, they do not rely upon the secrecy of the reference but upon their resistance, at least in context, to counterfeiting. Your visage is an authenticator for your drivers license. It is public information. While a photograph of you might be able to fool a computer, no other person would be likely to confuse the photo with you.  There is too little information in the photo for it to be mistaken for you.  The more information that the implementation uses, the lower the risk of false positives but the higher that of false negatives and the more power and time required for a check.  

Finally, as this article suggests, just like passwords, biometrics are fundamentally vulnerable to spoofing and replay attacks; implementations must resist them. For example, Apple's FaceID uses tests of "liveness" to distinguish between a real person and a photo of the person or a replay of an earlier submission.  Perhaps they are better used on mobiles, where possesion of the mobile is one factor and where the instant data is compared to the reference locally and does not go across a network where it could be captured for replay.  

The Desktop, our Achilles Heel

During the last three or four years the number and rate of enterpirse wide breaches have increased dramatically.  Successful attacks have relied upon duping users into clicking on bait malicious objects in e-mail messages and web pages.  The malicious objects capture user credentials and then use them to attack peer systems in the enterprise network, spreading the compromise laterally.  These attacks exploit user gullibility, re-usable credentials, the default desktop access control rule of ”read/write,”  and flat enterprise networks.  Therefore, many security practitioners recommend user training, multi-factor user authentication, and structured networks.  Resistance to all three of these measures is high and their effectiveness limited.  Moreover, they do not address the vulnerability of the desktops to have their procedures modified by their data.   We are left with a high level of risk.

E-mail and browsing are the Achilles Heel of the desktop and the desktop is the Achilles Heel of the enterprise.  One of these two applications are involved in a large percentage of all breaches.  Note that while Achilles was vulnerable on only one heel, small attack surface, the enterprise may be vulnerable on many desktops.                                                            

One obvious defense would be to isolate these two applications from the system on which they run and those systems from the other applications and systems of the enterprise.  Neither of those applications should have the capability to make persistent changes to the procedures of the systems on which they run.  

In a world of cheap hardware, one way to do this would be to run these two applications on sacrifical hardware dedicated to these two applications.  In a world of reliable process-to-process isolation, another would be to use that isolation to protect the system on which the applications run from any changes originating in those porous applications.  The first solution is resisted because IT culture sees hardware as expensive, this in spite of the fact that its cost halves every two years.  The second is resisted because user culture prefers convenience, generality, flexiblity, and ”dancing pigs” to security.  As a consequence, most desktops are configured to offer read-write access to most objects and  few provide reliable protective isolation.  

It does not have to be this way.  Ten years ago Steve Jobs and Apple introduced us to iOS, with very limited capabilities but with very strong process-to-process isolation and strong protection from anything done at the user interface.  As it has matured its capabilities have increased.  Controlled application-to-application communication has been introduced while maintaining strong isolation and protection.  Some generality and flexibility have been sacrificed to usability and security but less than the defenders of the status quo predicted.  Nonetheless, resistance to iOS was so strong that it provoked Android, a more traditional system.  

However, iOS has been adopted by a large population of users that enjoy ”most, but not all, of the benefits offered by the traditional general purpose system.” (Fred Cohen)  At the user application interface, it appears as a single user single application-only machine.  While it can maintain application state, iOS is resistant to any persistent change to itself from the application or the user.  

Said another way, iOS protects itself from its data, its user, and its user’s data.  While the application may be vulnerable to a ”bait” attack, the system is not.  Therefore, it is a preferred environment in which to run vulnerable applications like e-mail and browsing, and sensitive applications like banking and healthcare.   

Personal computers can be configured with hypervisors to provide strong process to process isolation.  They can be configured with the ”least privilege” access control rule to resist contamination of procedures by their data.  Said another way, they can be configured such that simply clicking on a bait object is not sufficient to compromise the system.  Indeed they can even be configured in such a way that, as in iOS, nothing done with the keyboard and mouse is sufficient to compromise the system. 

This brings us to the ”flat enterprise network.”  Traditionally, enterprise networks have been configured for any-to-any connectivity; any node in the network could send a message to any other node.  The latency and bandwidth between any two nodes was roughly the same as the average across all nodes.  Often, and at least by default, they have been operated at a single level of trust.  That is to say, all nodes in the network were assumed to be benign, orderly, and well behaved. Nodes were not expected to have to protect themselves from traffic that originated on the network or question the origin address.  It is this configuration that leaves the enterprise vulnerable to lateral compromise with little more than one compromised system or user credentials.  

The alternative and safer network is referred to as ”zero trust.”  All nodes are assumed to be mutually hostile.  Traffic may flow only between specified pairs, e.g., user to application or client to server. Origin addresses are not trusted but must be authenticated.  Some cost in latency or bandwidth is tolerated for authorization of the connection and mutual authentication of the nodes. This kind of network is resistant to lateral compromise; a compromised node can attack only the nodes to which it is allowed to send traffic.  Even those nodes will treat it with suspicion and may require evidence as to its identity.  

There are a number of ways to restrict the flow of traffic to accord to this policy.  The first and most obvious is to provide only links between authhorized nodes; easy for two nodes, illustrative, but it does not scale even to a small enterprise.   However, the others simulate this illustration, usually through the use of encryption, e.g.,virtual local area networks, VLANs. virtual private networks, VPNs, and software defined networks, SDNs.  Note that in SDNs, users are included as ”nodes.”  Note also that to be most resistant to attack, connections should be at the application layer.  Applications are the nodes of interest and, contrasted to, for example, operating systems, have the smallest attack surface, i.e., the user interface.  

So, to summarize, the traditional use and configuration of desktops leave the enterprise vulnerable.  While awareness and strong authentication, remain essential practices they are limited in their effectiveness.  E-mail and browsing should be isolated from mission critical or otherwise sensitive applications.  The environment should be resistant to persistent changes to programs or procedures from application data; least privilege access control.  Network traffic should be encrypted end-to-end at the application layer; prefer software defined networks to VPNs to VLANs.