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.  

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.  

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.  

Privileged Access Management

In its Private Industry Notification (20190423-001) the FBI specifically called out the risk represented by privileged users, those people who configure and manage networks, systems, applications, and users, those with administrator (e.g., "root," "ADMIN") pivileges.  These users are problematic because they can both expand their privileges and hide their use.  For example, an administrator might create a phony user ID to use to hide his activity or to use after termination.  The most egregious example might be the abuse by Edward Snowden who expanded his privileges to exfiltrate dozens of documents over months from the NSA without being detected.  

At the primitive level, most privileges are associated with a user identifier and a reuseable password.  In order to provide coverage, these are often known to and used by multiple parties with a subsequent loss of accountability, just where we need it most.        

However, there are solutions, called Privileged Access Management (PAM) packages, that can be used to provide some automated control and accountability over these users.  These applications work by acting as proxies for the privileged controls, hiding them, controlling access to them, and recording their use.  Instead of connecting directly to the privileged controls, the administrator connects to the proxy which then connects him to the privileged control.  

These packages may provide:

• hiding of all privlleged controls
• strong authentication of privileged users
• management control over the granting and withdrawing of privileges
• logging of all connections, events, and uses, content.
• multi-party controls (two or more people must cooperate)
• restriction of use to a time of day or shift
• restriction of use to specified (e.g., supervised) locations (e.g., device, network address, VPN, VLAN)
• restriction to a single user at a time (checkout/checkin) 
• other

The PAM becomes the sole process with access to the privileges and uses them on behalf of its user as directed by management or policy.  

If your enterprise, network, system, or application has only one privileged user or administrator, then you have good accountability;  whatever was done, that person did it.  However, that will apply to only very small enterprises.  Everyone else should be using a Privileged Access Manager.  There are now dozens on the market.  Choosing the right one will require some effort but the usual sources (e.g., Gartner, Capterra, Solutions Review) will assist you.

Limitations of Two Factor Authentication

In an opinion piece in the New York Times, Professor Josephine Wolff of Rochester Institute of Technology describes a “phishing” attack in which two factor authentication might not protect you.  The bait asks you to click on it to go to an application that you are authorized to use.  Clicking on the link takes you to a site that mimics the application.  It mimics the prompts for the user ID, the password, and the one-time password, all three of which it uses to logon to the real application in your name.  Unfortunately, to some readers this may read like a general limitation of two factor authentication rather than a special case.  Some users might conclude that two factor authentication is not worth the inconvenience.  

Consider some of the conditions for the success of this attack.  First the bait must be for an application to which you actually have an account.  Second, the bait must be sufficiently well crafted to convince you that you want to respond.  Third, you must respond, not by going to the application the way you usually do but by clicking on the bait.  Of course, this is very bad practice.  

While if this man-in-the-middle attack is sufficiently well designed as to fool you, it has only stolen a session that you started. Unlike simple passwords it cannot be use to initiate a session on its own.  It has not exposed you to fraudulent reuse of your credentials.  It cannot be used to compromise other systems “laterally” within the enterprise.  

Well designed applications will not permit the attacker to turn off the two factor authentication without requiring a second one time password and will confirm any such change out of band.    

This is not the only possible successful attack against two factor, depending upon the implementation.  Consider Google’s implementation.   It offers the user five different choices of how to get the one-time password (OTP), in an SMS text message, in an e-mail message, in spoken language over the phone, from a software generator, or from a hardware token (Google Titan).  All of these must ensure that the OTP come from and get to the right place.

For example, SMS text and voice over the phone rely upon legitimate user’s control of the phone number.  E-mail requires that the OTP be sent to the legitimate user’s address.  Attackers have been successful in duping the carrier support personnel into pointing the the number to a new SIM or phone that they control.  They have also been successful in duping the application support personnel to change the number, or e-mail address to which they send the one time password.  Good practice requires that the change be confirmed out of band.  After compromise the user will not get one time passwords, or perhaps even phone calls, that they are expecting.   

Even software and hardware tokens rely upon the right token being associated with the legitimate user.  In order to compensate for lost or broken tokens, most applications provide for enrolling new tokens.  An attacker might succeed in duping support personnel into enrolling their token in place of the one heldby the legitimate user.  

Note that all of these attacks require work and special knowledge.  None of them guarantees success, none of them scales well.  Those that permit fraudulent reuse, also deny the legitimate user access and should be obvious.  

Two factor authentication using one time passwords is a special case of “strong authentication,” defined as multiple forms of evidence at least one of which (e.g., one time passwords) is resistant to replay.  Note that security can be increased by using more forms of evidence.  This at the expense of convenience.  

Strong authentication should be preferred for most applications.  Simple passwords must be used only for trivial applications.  All security mechanisms have limitations that we must understand and compensate for but that does not make them unuseable.  We must not permit the perfect to become the enemy of the good.  

Limitations of One Time Passwords

Recently a man sued AT&T because his one time password was sent to the wrong phone, causing him to lose $24M in “cryptocurrency.”  To punish them, he asked for $200M in punitive damages.  This led to headlines talking about the “dangers” of relying upon SMS to deliver one time passwords.

These are not so much ”dangers” as they are ”limitations.” ”Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.” All security measures have limitations. Perfect security has infinite cost; we must not let it become the enemy of good security.

While one time passwords, whether sent from the server or generated at the client, are orders of magnitude more secure than reusable passwords, they still have limitations.  They must be properly associated with the user or his account.   Like most security measures, and as in this case, this association is vulnerable to social engineering attacks.

Some of you may have tried to register a new SIM or move an existing phone number from one device to another.  You can testify that it can be a pain; the carriers have stringent security procedures in place to resist fraudulent changes to your account. However, they have hundreds of agents handling provisioning requests and they are trained to be customer friendly. In pursuit of this, they can be expected to make mistakes. That is a limitation of using your phone and its number as part of your authentication scheme.

Note that if you do not get a one time password, or a phone call, or even a paper bank statement that you are expecting, you may have been compromised. Note also that the carriers are not the only targets of these ”social engineering” attacks. The attackers may try to get your account holder to change the phone number, e-mail or street address in your account record from your number to theirs. That is why responsible account holders will send you an out-of-band confirmation of all changes to your account record to both the old and the new address. Even hard tokens may be vulnerable to these attacks because the account holder must be able to respond to lost tokens by allowing you to register a new token. Again, not so much a danger as a limitation. Keep in mind that just twenty years ago, the scam was to request a postal address change.

While I use SMS for Google, Dropbox, PayPal, Amazon, my credit union, and my banks, I use a token for my brokerage and retrirement accounts. Note all of these offer me choice of SMS or tokens. ”Horses for courses.” Rest assured that I would not use SMS for $24M. In fact, I would never put all that in one account.

Even as users, we need to know the limitations of the things that we depend upon for security.  As security professionals, responsible for choosing, applying, and operating these mechanisms, it is mandatory.

The Use of SMS for Strong Authentication

NIST and others have discouraged the use of SMS for strong authentication.  This is another case of the perfect as the enemy of the good. 

First, strong authentication using a one time password sent via SMS is dramatically more secure than a replayable password. Second, if you get a one-time password when you ask for it, you are safe.

The problem is not so much with SMS but with the (cell) phone number. There is a risk that an attacker can either change the number in your account, to which the one time password will be sent, to a number other than yours, or get the phone company to associate, re-assign, your number with their phone. In either case, you will not get the one time password when you ask for it. In the latter case, you will not even get phone calls. Whenever the cell phone number in your profile is changed, you will get an e-mail message asking you if you really did it.

Carriers have controls in place to resist fraudulent reassignment of numbers to new phones.  However, the large number of agents and their desire to be accommodating, makes them vulnerable to ”social engineering” attacks. 

The difference in risk between a one-time password sent to your phone and one generated on board is small, particularly when compared to the difference in risk between either and a reuseable password.

In certain circumstances, the difference in convenience may be great. I have ten different accounts associated with my cell phone number. If I get a new phone, all my accounts continue to work as they did on the old phone. The number has moved to the new phone. If I used an on-board password generator, not portable to the new phone, I would have to register the new password generator with each of the ten accounts. I have to do that by calling support, authenticating myself, and registering the new generator. Until I have done that, I cannot logon to or use the account.

If you think about it, the real risk is in provisioning of the phone number or the registering of the on board generator (e.g., VIP Access, Google Authenticator, RSA SecurID Software Token). 

Internet Vulnerability

On March 24, 2017 Gregory Michaelidis wrote in Slate on "Why America’s Current Approach to Cybersecurity Is So Dangerous."

He cited an article by Bruce Schneier.

In response, I observed to a number of colleagues, proteges, and students that "One takeaway from this article and the Schneier article that it points to is that we need to reduce our attack surface.  Dramatically.  Perhaps ninety percent.  Think least privilege access at all layers to include application white-listing, safe dcfaults, end-to-end application layer encryption, and strong authentication."

One colleague responded "I think one reason the cyber attack surface is so large is that the global intel agencies hoard vulnerabilities and exploits..."  Since secret "vulnerabilities and exploits" account for so little of our attack surface, I fear that he missed my point.

While it is true that intelligence agencies enjoy the benefits of our vulnerable systems and are little motivated to reduce the attack surface, the "hoarded vulnerabilities and exploits" are not the attack surface and the intel agencies are not the cause.  

The cause is the IT culture. There is a broad market preference for open networks, systems, and applications. TCP/IP drove the more secure SNA/SDLC from the field. The market prefers Windows and Linux to OS X, Android to iOS, IBM 360 to System 38, MVS to FS, MS-DOS to OS/2, Z Systems to iSeries, Flash to HTML5, von Neumann architecture [Wintel systems] to almost anything else.  

One can get a degree in Computer Science, even in Cyber Security, without ever even hearing about a more secure alternative architecture to von Neumann's [e.g. IBM iSeries. Closed, finite state architecture (operations can take the system only from one valid state to another), limited set of strongly-typed (e.g., data can not be executed, programs cannot be modified) objects, single level store, symbolic only addressing, etc.)]

We prefer to try and stop leakage at the end user device or the perimeter rather than administer access control at the database or file system. We persist in using replayable passwords in preference to strong authentication, even though they are implicated in almost every breach. We terminate encryption on the OS, or even the perimeter, rather than the application. We deploy user programmable systems where application only systems would do.  We enable escape mechanisms and run scripts and macros by default.

We have too many overly privileged users with almost no multi-party controls. We discourage shared UIDs and passwords for end users but default to them for the most privileged users, where we most need accountability. We store our most sensitive information in the clear, as file system objects, on the desktop, rather than encryptied, in document management systems, on servers. We keep our most sensitive data and mission critical apps on the same systems where we run our most vulnerable applications, browsing and e-mail. We talk about defense in depth but operate our enterprise networks flat, any to any connectivity and trust, not structured, not architected. It takes us weeks to months just to detect breaches and more time to fix them.  

I can go on and I am sure you can add examples of your own. Not only is the intelligence community not responsible for this practice, they are guilty of it themselves. It was this practice, not secret vulnerabilities, that was exploited by Snowden. It is this culture, not "hoarded vulnerabilities and exploits," that is implicated in the breaches of the past few years. It defies reason that one person acting alone could collect the data that Snowden did without being detected.  

Nation states do what they do; their targets of choice will yield to their overwhelming force. However, we need not make it so easy. We might not be able to resist dragons but we are yielding to bears and brigands. I admit that the culture is defensive and resistant to change but it will not be changed by blaming the other guy. "We have seen the enemy and he is us."

Lessons From the J P Morgan Chase Breach

A recent report suggested that the J P Morgan Chase breach teaches us the importance of encryption.

We know that information was recovered in the clear. What we do not know is whether encryption would have been effective in protecting it or even whether it was used but was not effective.

What we do know is that the credentials of authorized users were compromised and used to access the data. Authorization to the data includes the ability to see it in clear text even though it might be stored in encrypted form.

Encryption is not magic. It is a tool. Government propaganda to the contrary not withstanding, it is no more perfect security for the bank, than it is for the criminal.

Encryption is used to restrict access to data at rest, for example on file servers, from those who do not have credentials to access the server. It is used to protect data in transit, for example user credentials, as they cross networks. Properly used, it is very powerful. It is not effective against those with the credentials, the authorization, whether legitimate or otherwise, to access the data.

Are there many banks that are storing information in the clear that should be encrypted? Yes. Was JPMorganChase one of these? We do not know; that information has not been disclosed. Should all banks take to heart the lesson that they should be using encryption to protect data at rest? Yes. Does that lesson flow from the "breach" of JPMorganChase? No, but it does flow from the "attacks."

What we do know is that of the thousands of applications and servers at JPMorganChase, fewer than a hundred were compromised and none of those were using strong authentication. So, the first lesson that I want banks to take from the JPMorganChase breach is to use strong authentication, particularly for privileged users of applications, databases, and servers. Without this, encryption is not likely to be effective.

Strong authentication is policy at JPMorganChase and appears to have been effective where used.

A Leapfrog Enterprise Security Strategy

Recently I was quoted in an article on newly reported, but somewhat old, breaches.  In the report I was quoted as suggesting that these breaches suggest that security has fallen behind and that, just in order to catch up, we need a "leapfrog" strategy.  This post will suggest what such a strategy might contain.

Mine would start with strong authentication close to the users, i.e., at the end point. Strong authentication will start with privileged users and move to all employees. We have known about the limitations of passwords and what to do about them for thirty years. It is way past time to get on with it. Going forward, the end point of choice will be the mobile computer, colloquially referred to as a "smartphone."  This device already contains powerful sensors that can be used for authentication of claims to identity.  Apple Touch ID and Samsung Face Unlock are simply early examples of what can be done.  These are quick and easy to use and, in combination with possession of the device, constitute strong authentication.  

My strategy would include reducing the number of privileged users, the reduction of their privileges, and accountability for the use and exercise of privileges. It would include involving two or more people in the exercise of sensitive but rarely used privileges. We have too many privileged users and too little visibility into how those privileges are used.

It would include the automatic notification of the subjects of records and the owners and managers of accounts of all use, changes to, or transactions against those records or accounts. If we are to detect breaches on a timely basis, we must increase and improve transparency and accountability.

It will include isolating e-mail and browsing from mission critical and other sensitive systems and data. The intelligence is clear that many, not to say most, compromises begin by duping the users of these two applications.

It will include end-to-end end, end-point to application, not perimeter, not operating system, encryption. We cannot continue to operate large enterprise networks as flat spaces, as spaces in which any system may address any other system in the network.

It will include restrictive, i.e., "white list only," granular access control close to the applications and data. It will probably include access control at every layer, e.g. between the application and the database, between the database and the file system.

These measures are neither expensive nor disruptive. Google has demonstrated that even strong authentication can be flexible and convenient. They can be implemented in parallel. There are vendors recommending them and with products and services to implement them.

This is an "off-the-top of my head" list; I am sure I have omitted something important. However, it is informed by fifty years of thinking about this problem. I am sure that many of my colleagues have measures not on my list but which they would include in a leapfrog strategy.