On "Patching"

IT projects are historically, not to say always, late.  There are a number of reasons for this.  We prioritize schedule before quality; it is part of our culture.  We think that schedule is easy to measure. We think that we are on schedule until late in the effort, when quality jumps up and bites us in the ass.  Another reason that we are late is that we fix things in the order of their discovery rather than in the order of their importance.

This is a way of behaving that we replicate in Cybersecurity.  Not only do we fix things in the order of their discovery but we fix them in the order that someone else discovers them.  Microsoft announces forty vulnerabilities, ten critical, on "patch Tuesday."  We drop anything else we might be doing to apply the patches.  

Microsoft was shamed into publishing one or more of the patches.  Google Project Zero discovered the vulnerability and generously gave Microsoft ninety days to fix it under the threat of a public shaming if they failed.  

Ninety days is arbitrary.  It is not based on the ease of exploiting the vulnerability, how wide spread it is, how costly it is to fix, what the fix might break, or what other vulnerabilities Microsoft may have on its plate.  It is one size fits all.  Sometimes Microsoft even chooses the shaming, in part because of what it knows that Google does not and cannot know.  We often patch without even considering whether or not the vulnerability represents a risk to us.  

Again, it is part of our culture.  Of course, as a result of this automatic, Lemming like, behavior, we may all be at greater risk than we need to be.  

Whatever our vendors or our peers may be doing, we need to fix things in order of their risk to our enterprise.  We need to resist letting others allocate our scarce resources into "unplanned activity."  We need to put aside fear generated by the breach of our neighbor because of an unapplied patch.  

Know your risk tolerance.  Identify your risks.  Mitigate, accept, and assign them in the order of that risk.  Document risk acceptance.  Plan your work and work your plan.  Prefer mitigation measures that are broad over those that are merely most effective.  Keep in mind that hiding vulnerabilities, for example behind firewalls, is often more efficient than patching them.  At least the mistakes you make will be your own.

FBI Recommends Use of Biometrics

In its Private Industry Notification, 17 September 2019 PIN Number 20190917-001, the FBI encourages the use of biometrics to resist what they see as the limitations of strong authentication.  In fact what they have observed is effective social engineering attacks necessitated by effectiveness of one-time passwords.  Other strong authentication, which might include biometrics, is the solution that I would recommend.

Consider my financial services firm.  They offer me strong authentication based upon a software token installed on my mobile computer.  I downloaded the token from the App Store and gave its identity, 4 letters and 8 digits, to my financial services firm and they associated that token with my account.  When I logon with my UID and password, I am prompted for a one-time password, six digits, generated by that token, with a life of sixty seconds, and expected by a server used by my financial services firm.  

Now, suppose I were to lose the mobile.  I would have to get a new mobile and download a new token.  I would have to associate the replacement token with my account.  In the capability to do that lies a potential vulnerability.  If an attacker were successful in convincing my financial services firm to associate his token with my account, then he might be able to defeat the strong authentication.  Therefore, my financial services firm must be able to resist this "social engineering" attack.  This is where biometrics can play a useful role.

When I call my financial services firm to replace my lost token, or for any other purpose, they may recognize me from my "calling number ID."  They authenticate me by my voice, a biometric, something that only I can do, one that works over the phone.  Yep, they really do; they tell me that that is what they are doing.  While I am a stranger to the agent, the computer recognizes my voice as the one to expect for my phone number.  The agent also asks me for another piece of shared information, a challenge and response, a second factor.  Only then will they honor my request to replace the lost token ID with the the new one.  I think that this is an instance of the use of biometrics that would meet the expectation of the FBI.  

Of course, the process does not end there.  My firm e-mails me, out-of-band confirmation, that they have changed the token associated with my account.  This gives me the opportunity to recognize a fraudulent change to my token ID.  

Now the link above not only points to my blog entry on limitations of one-time passwords but also to the limitations of biometrics.  One needs to understand those limitations in order to use biometrics effectively.  I like the voice implementation used by my financial services firm because it is dynamic and resists replay attacks; replay attacks are one of the limitations of biometrics.  Along with facial recognition, voice is one of two biometrics that both people and machines can reconcile reliably.  

(I am sure that you have heard of static facial recognition being duped by a photograph, a limitation, but fooling a four year old child in dynamic facial recognition, for example, over Skype or FaceTime, as to the identity of her grandmother might be more difficult.)

While there are alternatives to the use of biometrics, the FBI and I agree that they can be both convenient and secure in some applications and environments.  The FBI recommends them to resist what they see as limitations of multi-factor authentication.  I recommend them as effective and efficient measures for resisting one form of "social engineering."

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.  

Do not Rely Solely...

I often tell small children that "in the future most of your toys will talk and listen and generally tell the truth; when in doubt ask Dad."

However, this is the age of disinformation, "fake news," and state propaganda.  Our children will confront errors and deliberate lies.  At some level, we all know that Fox, CNN, and MSNBC have agendas, biases, that make them less than totally reliable.  We need to equip our children to recognize and cope.  

I like Wikipedia, I think that it is one of humanity's greatest achievements, in part because it relies for its authority on its users.  Teachers question the authority of Wikipedia: they prefer the Britannica, in part because it relies for its authority on scholars like themselves.  They prefer it even though it is only one-sixth the size of Wikipedia and much more difficult to use.  However every night when I go to bed, I give thanks that Wikipedia is a little better than it was when I got up in the morning while the Britannica is just as bad.  Wikipedia is self correcting.  

The net is that we want our children to think critically, to be skeptical, to be able to separate facts from opinion, what is important from that which is trivial, to prefer primary sources, to prefer neutral sources, PBS and C-SPAN before Fox or MSNBC.  Perhaps the single most important tool that we can teach them is to check multiple sources.  

Security by Obscurity

According to Wikipedia, "Security through obscurity is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component. Security experts have rejected this view as far back as 1851, and advise that obscurity should never be the only security mechanism."  Labeling the other guy's security strategy as "security by obscurity" is how we disparage it.  

However, looked at another way, all information security is about secrecy, if not obscurity.  What we think of as security can be seen as the collection of mechanisms that we use to reduce the size and number of the secrets that we must keep. 

Encrypting an object reduces the problem of hiding the file to one of hiding only the key.  Access control may reduce the problem of hiding user capabilities and privileges to one of hiding the user password.  

Out of Band Confirmation

This morning I sent a gift via PayPal to a family member, one to whom I had never sent one in the past.  The transaction was initiated using the PayPal iOS app.  It included an out of band one time password and was from a device that PayPal recognized.  Almost immediately, I got an e-mail confirming the transaction.  About an hour later, I received an SMS message from PayPal asking me to confirm that I had initiated the transaction.    When the charge hits my little four branch community bank, I will receive another e-mail and another SMS from them.  Incidentally, I also got a "thank you" e-mail from the family member.

If I had used a new device to initiate my transaction, the web instead of the app, or changed my e-mail, cell number, or bank accounts, PayPal would have confirmed those activities.  For changes to my e-mail or cell number in my PayPal profile, PayPal would confirm those changes to the other address and for the address changed to both the new and the old addresses.   So will, for example, American Express, Fidelity, BoA, and Chase.

How much of this is by design, I do not know.  What I do know is that, if my transaction was not properly authorized, PayPal, my bank, and I would have ample opportunity to learn about it on a timely basis.  

Having two or more addresses for our customers, two ways to get a message to a device carried in one's hand, pocket, or purse, makes this control more effective than ever.  The cheap and fast communication provided by the modern public networks makes them so efficient that it could be considered negligent, even reckless, not to use them.  

What continues to concern me is that when I go to fraud conferences, I may be the only one to talk about "out of band confirmations," perhaps the single most powerful fraud detection mechanism that we have.  

Please put this tool in your kit.  Promote it every chance you get.  Ensure that it is included in all your applications.  Confirm all transactions and new or changed user profile data.  Confirm to every address that you have.  Confirm address changes, postal, e-mail, phone numbers, and device identities, to both the old and the new address.

Apple Titanium Card

I have been waiting for the delivery of my Titanium Card to be delivered to write this evaluation.  Read it in the context of my last post.  

The card is delivered via FedEx in a large envelope.  There is a return address but it does not say "Apple."  This resists theft of the card in transit.

Inside the FedEx envelope is a tamper evident 4.5" x 6.25" x 0.25" corrugated cardboard package containing the card.  This protects against tampering with or skimming the card in transit.  

While a signature is not required for delivery, one gets a notification of delivery.  This may narrow the window of opportunity for theft from the doorstep.  

Only after receipt does one see the button in the Wallet App to "activate" the card.  This resists any use of the card prior to receipt by the legitimate owner.  

While the owner's name is on the face of the card, the card number, expiration date, and the CVV are not.  While the number is on the magnetic strip, unlike with all other cards, it is different from the number that one would use at an e-commerce site.  Thus, the only way that one might monetize knowledge of the number would be to use it to counterfeit a card.  

Note that any fraudulent use of the number on the stripe will show up immediately on the owner's iPhone so that the transaction can be reported as fraudulent and the number can be reported as compromised.  Skimming the number and counterfeiting a card for one or two uses is a high hurdle.  

The value on the magnetic stripe, provided for backwards compatibility, on a card which will be used sparingly, is a limited vulnerability.  From a security perspective, consumers should prefer Apple Pay (using iPhone of Apple Watch), EMV, manual entry of the number (from the iPhone Wallet App), and swiping the magnetic stripe in that order.  While the magnetic stripe is more convenient than manual entry, many users may never have to use either.  As point of sale devices are modernized, the requirement for any alternative to contactless or "chip" will decline.  

Finally, in the app, one can disable and enable the card.  Thus one can carry the card while mitigating the risk of fraudulent use should it be lost or stolen.  Since I expect the use of the Titanium card to be sparse, mine remains disabled by default.  Others may choose to leave it enabled by default, disabling it only should it be lost or stolen.

The vulnerability of the number on the magnetic stripe is not limited to the Titanium card; so far it is not possible to get any other credit card without this vulnerability.  On the other hand, the Titanium card does not have the vulnerability of having the primary account number, the expiration date, and the CVV on the face.  Therefore, if one is going to carry a credit of debit card with a number in the clear on the magnetic stripe, the Titanium card is the clear favorite.  

(Incidentally, I convinced myself.  I got the Titanium card, intending to put it in the drawer and never carry it.)

Recommendations on Retail Payment System Security

According to the Nilson Report, Global Credit card and debit card fraud resulted in losses amounting to $21.84 billion during 2015.  Losses have increased every year since 2002.  While the majority of these losses are charged to the card issuers, the cost is passed along to the consumer in the form of interest charges and fees.  (See sources and other statistics at WalletHub.)

Moreover, we have seen the growth of an illegal industry attacking and stealing personally identifiable information, and monetizing that information using credit and debit card account numbers, ATMs, and e-commerce.  In the market place of this industry it is possible to buy active primary account numbers and authenticating data.  The size and complexity of this industry makes it all but impossible to estimate its cost to the legitimate economy.  

Given the number of enterprises collecting, communicating, and retaining this data, some leakage is inevitable.  However, it is the ability to monetize the data that supports the illegal trade and which motivates many of the active attacks.  While we have seen some arrests and convictions in the illegal industry, many of these attacks and the fraudulent use of the data are going unpunished.  

It is the author's assertion that one means of reducing this illegal trade is to reduce the storage and use of primary credit and debit card account numbers.  Specifically we propose the elimination of the primary account numbers on the face of the card, the magnetic stripe, in the transaction, and in storage on merchant sites; all of these uses to be replaced by physical and digital tokens.  In most cases, the Payment Authorization Number (PAN) should be a digital token rather than the primary account number.  We assert that the financial  technology and payment card industries already know how to do this, that there are demonstration projects ongoing, and that much of the necessary infrastructure to do this is already in place.  

The new Apple credit card is an example of a physical token that hides the primary account number.  Contactless EMV cards and mobile wallets are examples of digital tokens at transaction time.  While the current practice is to put the primary account number in the clear, both in text on the face of the card and on a magnetic stripe, this is for purposes of backwards compatibility, is archaic and unnecessary, and, in the light of the problem outlined above, should be eliminated.  

Some merchants have already replaced the primary credit card account number in their customer record with a digital token.  While this may add a little cost it reduces the risk of attacks against their systems and that the account number can be compromised in a breach.  

PayPal, Masterpass, AmEx Express Pay, Apple Pay, and Visa Checkout are all examples of services for authorizing e-commerce payments without the use of the credit or debit card account numbers.  These systems not only guarantee the merchant payment but transfer the cost and risk of authenticating the customer name and address to the service provider.  While the services may marginally increase the transaction cost to the merchant, this is more than offset by the reduction of risk.  These services also reduce the risk to the consumer of the leakage and fraudulent use of his account numbers.  

We recommend the following:

• The elimination of the magnetic stripe from all newly issued credit or debit cards
• The use of one-time Payment Authorization Numbers  (PANs) throughout the payment system
• The replacement of primary account numbers with one-time payment authorization numbers in e-commerce
• The replacement of primary account numbers with digital tokens in merchant systems storage
• The replacement of mag-stripe and PIN at ATMs with EMV
• Preference for digital wallets at point-of-sale and ATMs
• The elimination of the primary account number in text on the face of cards
• Prefer EMV cards with biometrics for convenience and security

These recommendations are intended to address the systematic problems in the retail payment system.  They are independent of one another and each can be implemented, in whole or in part, by itself.   However, they do compliment one another and collectively are necessary to the greatest effectiveness.  The first is the most important and the only one for which there are no trials or demonstrations.  Every little bit will help.

We recognize that implementation of these recommendations will take time but it is urgent and should be done within 3-5 years.  While we believe that these recommendations are self-justifying, we recommend that mechanisms like the Payment Card Industry Data Security Standards and California and New York legislation be used to add motivation as necessary

The Budget Fairy

It is a persistent plaint of the security managers that they do not have sufficient budget to do what they think should be done.  One wonders where they think budget comes from.  There is no budget fairy that comes down and confers budget on good little boys and girls. Those managers who have budget all got it the same way; they asked for it.  

Security managers are peculiarly loath to ask for budget for fear they will be told no. (A "no" in the record might look bad but it is an implicit acceptance of any risk that the proposal was intended to reduce.  It should be in the record.) Those who ask for budget get told no a lot. Those who have budget did not take no for an answer. They re-did their proposal or their justification and asked again.  And again.  As many times as necessary to get to yes.

Note that almost anyone in the hierarchy can say no.  Those who have budget, find the executive or manager who can also say yes.  They never accept no for an answer until they are sure that they have proposed to someone who can say yes if she wants to.  Note that while we may sometimes get budget from senior staff, it is usually the line of business executives who control most of the resources and incur losses.  (Senior line of business executives often have "budget" or "plans and controls" staff, who manage budget, understand the process, and know how much discretion the executive has.  These staff can be very helpful.)

Those who have budget are the same managers who are being promoted.  General management likes few things better than managers who will tell them how to spend money profitably.

Security initiatives are usually justified either by a reduction, at least over time, in the cost of security or the cost of losses.  These reductions have the advantage that they fall through to the bottom line as profit.  It is useful to budget for "losses;" while they occur irregularly, they do occur.  At least at the level of the enterprise or business unit, they can be estimated; all budgets are estimates but get more accurate with experience.  Increases in the budget for initiatives can be justified in part by a reduction in the budget for losses.  

Managers often see budget as a restriction on their ability to spend.  Rather they should see it as permission.  

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.

Control of Privileged Insiders

On April 23, 2019 the FBI published a Private Industry Notification (20190423-001).  The document was distributed as a pdf only by e-mail.  While marked “TLP-White,” “may be distributed without restriction," I could not find it on the web.

The summary read:

The FBI continues to observe U.S. businesses’ reporting significant losses caused by cyber insider threat actors.  These cases often involve former or disgruntled employees exploiting their enhanced privileges—such as unfettered access to company networks and software, remote login credentials, and administrative permissions— to harm companies. Cyber insider threat actors most often are motivated by revenge, but they also conduct attacks to profit financially from stolen information, gain a competitive edge at a new company, engage in extortion, or commit fraud through unauthorized sales and purchases.

I recommend it to the reader.  (Since I cannot find it on the web, here is a link to a private copy.)

There are two kinds of insider risk, accidental and intentional, and three threat sources, benign, dishonest, and disgruntled employees.  Note that insider threat rate is much lower than the outsider threat but the consequences, and therefore risk, may be much greater.  Outsiders damage the brand while insiders may bring down the business.

Not only is employee error by otherwise well motivated and intended employees perhaps the biggest source of losses ("The dummies have it, hands down, now and forever."  --Robert H. Courtney)  but it contributes to the success of attacks by outsiders. (Think “phishing” and other forms of duping.)  Undetected errors may result in employee temptation and fraud.  The employee makes an error and no one notices.  She repeats and still no one notices.  She finally concludes that she could do it in her own favor and still no one would notice.   We distinguish between dishonest employees, who want to keep their activities secret, and disgruntled employees who want you to know that you have been injured.  

Management supervision is the most effective of all insider controls.  Effective supervision usually requires that the supervisor could do, or at least appreciate, the job being supervised.  This control often breaks down for privileged IT jobs.  The more sensitive or unique the task to be supervised, the more narrow should be the span of control.  While one might be able to supervise a dozen tellers or coders, one might supervise no more than five or six loan officers, system designers, or privileged administrators.  

The limitation of supervision is cost; while it is effective, it is also expensive.  Therefore, other more efficient and complimentary controls are often substituted for all or part supervision.  These might include background checks, training, division of responsibility and privileges (so-called multi-party controls), cross training, job rotation, measurement, mandatory vacations, audit trails and audits, recognition, compensation, and complete and timely separation.  

I had been writing and talking on this subject for a few years before I added “please and thank you” to my list of controls.  While equitable compensation is a powerful control, no amount of it can compensate for inadequate recognition.  Many dishonest and most disgruntled employees feel that their contribution to the enterprise has not been appreciated.  Please and thank you go a long way toward maintaining necessary morale.  

The FBI notification gives special attention to IT personnel and, especially, privileged users such as system administrators.  Management often focuses on lower level employees, like tellers or clerks, doing routine tasks.  Where these engage in fraud they get little and are caught early.  It is professionals, managers, and executives who bring down the business.

It is ironic that these highly privileged actors are often inadequately supervised, under paid, and unaccountable.  We caution against the sharing of user IDs and passwords, but it is privileged IDs and passwords that are most likely to be shared.  Many administrators have so much privilege that they cannot be held accountable, can escalate their privileges, and the privileges, once granted, cannot be effectively withdrawn.  Think about the privileges that Edward Snowden had to have accumulated to gain access to all the information that he exfiltrated.  

One should not grant privileges that one cannot withdraw.  Therefore, privileged users should be required to use hardware token based strong authentication.  One should not grant privileges without accountability for their use.  Therefore, when there is more than one privileged user, i.e., in most large enterprises, Privileged Access Management (PAM) controls should be in place.  These controls will be covered in a later post.

The Universal Serial Bus

This weekend there was a report out of Mar-a-Lago that a Chinese national had been apprehended while trying to enter this resort while carrying a laptop, 4 mobiles, and a USB thumb drive containing malicious software.  While thumb drives are an efficient attack vector, where the attacker has physical access to a computer, we continue to hear reports of people surprised at how easy it is.  

It is important to decode, to understand, “USB.” It stands for “Universal Serial Bus.” “Universal” refers to the standard; thousands of different devices employ the standard for interoperability. It is a standard interface but it is more than that. It attaches to the bus of the host device as peer with processors, memory, and other external input/output devices. The standard provides for the device to contain executable software to facilitate its attachment to and interaction with the host device.  Think of it this way; any device attached to the bus is logically an internal, not external, device.  

Like many standards, this one is popular, in large part, because it is convenient.  It is an open interface for attaching cameras, scanners, printers, speakers, microphones, head sets, monitors, and storage devices.  As is often, not to say usually, the case, convenience trumps security.  Any control that limited the attachment, i.e., was more secure, would make it less convenient.

It is a privileged form of attachment; no authentication, no cryptography, no control. It is subject only to physical access control. Simply plugging a USB “thumb drive” into the bus of another device is sufficient to alter the fundamental operation of, not to say corrupt, that device in, perhaps, as little as tens of seconds. As we have seen, compromise of a single device on a network may reduce the cost of attack against all other devices on that network.

Since most, not to say all, personal computers expose their bus via the USB standard, it is essential to prevent unauthorized physical access to all such computers.   (Indeed the interface is so ubiquitous and so vulnerable that some security professionals advocate filling the port with superglue.  This measure should be considered for sensitive systems and applications and hostile environments.)  

  

New Paradigm

Just watched the Tom Field, Steve Katz “interview.”

I might have identified one or two new threats or changes to the environment. Not sure I would do anything different as a result of what I heard. We need drastic changes to security to address the applications and environments that Steve described. I used to believe that risk increased in proportion to use, uses, and users but now it is increasing exponentially. We are around the knee of the “hockey stick” curve.  Doing the same things harder is not cutting it.

We need strong authentication, adaptive authentication, federated identity, end-2-end application layer encryption (Network Defined Security) (“zero trust”), “least privilege” access control (or at least “read-only” or “execute-only”), multi-party controls for sensitive capabilities, strong accountability and control for privileged users (PAM), and greatly improved pro-active threat detection. We need out-of-band confirmations and alerts for all transactions, many data changes, and some uses. We need document management systems for intellectual property. Some enterprises may be doing one or two of these, almost none are doing all of them.  

See my interview with Peter Denning.  https://dl.acm.org/citation.cfm?doid=3314328.3306614

Interview in the Communications of the ACM

In this article, I argue that there is a significant difference between today’s state of security practice, in which convenience trumps security, and the real requirements.  The current practice leaves us vulnerable to the threat sources and their attack methods that we are seeing.  I make a number of recommendations for changes to the practice.

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.  

 

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.