On Resisting Check Fraud

 When I first began to bank in the 50s, we did not have pre-printed personal checks or account numbers.  The only identification on a personal check was the signature.  The operators who processed the checks, identified the account from the signature.  While this was an error prone process, they were very good at it.

At the time, most checks were written by businesses.  We printed the checks on special paper, in multiple steps and fonts.  The amounts and signature facsimiles were often mechanically pressed into the paper rather than simply printed.  All of this was intended to make checks, particularly business checks for relatively large amounts, difficult to forge.  

Much has changed since then.  The introduction of MICR was the impetus for account numbers and pre-printed personal checks.  This not only reduced errors but also fraud. In the modern world, we use direct deposit for routine payments to those parties whose banks and account numbers are known to us.  While we still think of these as "checks," i.e., payments from demand deposit accounts, most are electronic and are never reduced to paper.  Even individuals may use "online banking," rather than writing checks, to make payments.  While some of these payments may result in the preparation of a paper check, it will not contain a signature for authentication.

Today, paper checks, when used, are often printed on plain paper in one step including the facsimile of the signature.  The bank does not rely on the paper to know that the transaction is authorized but on an out of band confirmation known as "positive pay."  In this system the check is sent to the payee and a message noting the amount and check number is sent to the bank on which it is drawn.  When the check is presented to the bank for collection it must reconcile to the message.  Actually, the paper is never presented to paying bank but is converted to an electronic facsimile by the bank of first deposit.  

 In the seventy years since I wrote my first check, I have only had one transaction turn on the authenticity of the signature.  This was last year on the pre-printed check to pay my real estate tax.  Admittedly, it really was a bad example of my signature.  I was impressed that someone was watching and checking.  

Reconciling signatures must be a very scarce skill these days.  That said, in addition to knowing their customers, banks are responsible for ensuring that transactions, e.g., checks, are properly authorized.  For business accounts, we now use "positive pay;" we do not rely on anything on the paper.  However, for individuals we take the risk, rely on the signature, return any questionable items, i.e., reversibility, or confirm out of band.  All of these involve cost.  Therefore, we use them in combination to minimize cost and risk.

On Over Classification

In the US government, we have a pervasive problem of over classification. https://www.cnn.com/videos/tv/2023/01/27/exp-gps-0129-fareeds-take-us-classification-system.cnn This results from a number of factors.  First, almost any author or officer can Classify data, that is specify, among other things, how much is to be spent to protect the data.  Said another way, he specifies how much others must spend to protect the data but may not incur the cost of protection himself.  

Second, the authority to classify, does not include the authority to change the classification.  Once the data has been labeled, often with a rubber stamp, it is too late to change it.  The implicit assumption is that the decision, once made, is irrevocable.  The decision is reviewable, even by a higher authority, but following a procedure specified for the class.  

 

Third, and as already noted, the classification includes a specification about the procedure that must be followed to lower the classification.  The higher the classification, the more rigorous and expensive the process.  Since the cost of declassifying may be equal to or even greater than the cost of declassifying, declassifying is rare.  

In enterprise things are a little different.  The authority to classify includes the authority to re-classify or declassify.  The classifier's authority comes from his role, it is not arbitrary.  Classification is normally limited in time.  Because sensitivity decreases with age, because we are normally protecting plans and rarely sources, by default classification ends automatically, usually in no more than three years, unless renewed.  

On "Sensitive but unclassified."

 In government "Classified," with a capital C, is a term of art.  It refers to data which the classifier believes requires some level of protection, rather than to the decision about the data.  This results in this strange expression.  To say that something is "sensitive but unclassified" is to classify it the sense of the literal English meaning of the word but not in the meaning of the term of art.  It is an attempt to get around the fact that the government has coopted the word Classified for its own use.

Can anybody tell me?

 Was there a written contingency plan for the failure of the NOTAM application?  Did it really say "shut down the industry?"  Had that plan been shared with the owners and users of the system?  Did they concur in it?  Obviously the flying public did not know.  What other remedies were considered and rejected in arriving at this plan?   Did the plan contain an estimate or an assumption as to the failure rate of the system?  Did the plan enumerate the failure modes.  Was operator error one of the enumerated modes or was it simply accounted for under "other."  Can anybody tell me? 

Can anybody tell me how much the shutdown cost?  How does that cost relate to the cost of the system?

One report suggested that there are roughly 30,000 records in the system but that perhaps as many as 5,000 are no longer current.  Can anybody tell me how many changes are made to this database in a day?  How many changes occurred during the shutdown?  

Another report suggested that the flight plan for an international flight might contain as many as 100 pages of NOTAMs.  Can anyone tell me what the signal to noise ratio is in the database?  

Please tell me that there was a plan and that it worked as intended rather than that this was a massive failure of management and governance.  Can anyone help me here?  These questions seem to deserve, not to say demand, an answer.   

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.)

Software Supply Chain

Microsoft has published a paper on Best Practices for a Secure Software Supply Chain.  https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices

You should not be surprised that it says Caveat Emptor.  It is all about how the buyer of software must manage the risk of any corruption in the supply chain.  It is silent on the supplier's, e.g., Microsoft, responsibility.  It simply assumes that some supplier in your supply change will ship you corrupt code, essentially with no accountability.

The issue first gained notice when a supplier, SolarWinds, having failed to manage the content of its product, shipped malicious code to all of its customers.  It's response, like that of Microsoft, was "Y'all be ca'ful, heah."  

Suppliers must be held accountable for all the code that they ship.  We have become so accustomed to poor quality code, and the huge cost of "patching" that comes with it, that this idea seems somehow foreign.  However, this issue is about code content, not quality.  

I do not propose to so reform the market that suppliers would be held accountable for implementation induced vulnerabilities in their code, for its suitability for its intended use, for its merchantabiity.  I only want them to be held accountable for malicious code, whatever its source, that they ship.  Managing the content of one's product, where it came from, may be related to, but simpler than that of ensuring that it is free of dangerous errors.  

I recently asked a colleague, a famous attorney, partner in a prestigious Washington law firm, why he thought that SolarWinds had not been sued for its gross negligence?  His answer was that the injured parties were enterprises, that they did not see themselves in the role of plaintiff.  

So called "software engineers" must be held accountable to the same standards that we hold all other "engineers."  Suppliers in the software supply chain must the held to the same standards as we hold other suppliers.  Software should not be synonymous with dangerous.  

Cost of Attack

For about a year now I have been arguing that we need to raise the cost of attack against our systems.  This is best justified by observing the rate of successful extortion attacks against our systems.  Few seem to be adequately resistant to such attacks.   

However, I am also mindful of the admonition of William Thomson, the First Baron Kelvin, who told us that if one cannot measure it, one cannot recognize its presence or its absence.  So, if one is to advocate for increasing it, one should be able to talk about how to measure it.   I use the mnemonic W.A.I.S.T.   These stand for work, access, indifference to detection, special knowledge, and time to detection and mitigation.  

The first letter stands for WORK.  The cost of attack will almost always include some effort on the part of the attacker, though, of course, some of this may be automated.  Take for example, a brute force attack against a password or a cryptographic key.  The cost is that of a trial multiplied by the number of necessary trials.  The number of trials required is a function of the number of bits, digits, or characters in the password or key.  One can increase the cost to the attacker by increasing the number of bits in the password.  (One can also reduce the value of success by changing the password or key after one use.)

For example, the cost of attack agains the Data Encryption Standard was defined as the cost of an exhaustive attack against the key.  While prohibitively high at the time of the publication of the standard, it was falling in proportion to Moore's Law, as was the cost of encryption.  Thus the DES implementers proposed Triple DES which raised the cost of attack by 2^56, is standardized for use until 2030 and will still be useful for some applications far beyond that.  

Note that the work of one person may be encapsulated in tools and procedures.  The cost of attack has decreased, been made more efficient, by attacker specialization and commerce.  One rogue may specialize in capturing credit card numbers while another may buy the numbers to monetize them in fraud. 

ACCESS is the second element of cost.  The attacker must have some kind of access to the target system.  Today that may be a network connection but in the early days, it meant physical access.  At a minimum an attacker must at least be able to send a message to the target system and observe its effect.  One can raise his cost by the use of physical isolation, "air gaps," gateways, firewalls, strong authentication, or encryption.  Note that strong authentication greatly increases the cost to the attacker while the ubiquitous mobile has been reducing its cost to the defender.  

INDIFFERENCE to detection is a little more subtle but so called "ransomware" illustrates it well.  Today's attacker believes that there is a low probability that he will be reported, investigated, identified, or punished for his attack.  We can increase his cost by increased monitoring, surveillance, and law enforcement.

SPECIAL KNOWLEDGE is often key.  It includes things such as user credentials, how applications work, such skills as programming, knowledge of the victims network architecture and others.  Interestingly enough, while it is often the most important thing that the perpetrator brings to the attack, it may be the one she herself least appreciates.  One will often hear hackers talk about the low cost of an attack, completely discounting the special knowledge and skill, often acquired over years, that they bring.  The attack looks cheap to them but would require much more of the other elements in the hands of another.

The defender may increase the cost of the special knowledge of the attacker by better operational security, so called OPSEC, choosing, identifying, changing, and protecting mission critical information.  We resist the acquisition of special knowledge about our systems, applications, and data by operating in a manner designed to resist the leakage of information about them that might be useful to an adversary.  These may include using code words, and changing key information.  Think TORCH, ULTRA, and MAGIC from WWII.  Think camouflage and disinformation.  Think product, application, and server names; better to call them "apple" and "orange," than "next generation product," "payroll" and "payables."  Think "trade craft."  

Finally there is TIME to detection and mitigation.  While some breaches can succeed in hours to days, others may require weeks to months.  Again ransomware attacks are of special interest.  The time from attack initiation to successful compromise of the victims entire network has been shrinking from weeks to days, in part from the tools, skills, knowledge, improved efficiency of the attackers.  The defender can reduce the time available to the attacker by improved surveillance, detection, and threat intelligence.  

Perhaps the most efficient way to reduce the time to detection and mitigation is out-of-band confirmation of all sensitive activity.  Kenneth Chennault, the President of American Express, told the President of the United States, that by confirming credit card charges using instant messaging, AmEx was often able to detect fraudulent transactions within sixty seconds.  

Note that these elements are fungible; an excess of any one, especially special knowledge, may decrease the need for the others.  If the attacker already has knowledge of a vulnerability, credentials, or applications, then the amount of work or time to detection required may be considerably less.  Increasing the cost of any one, increases the total cost.  Increasing them all proportionally mayincrease that cost exponentially.  

Three cautions:

• "An ounce of prevention is worth a pound of cure."
• "Never spend more mitigating a risk than tolerating it will cost you."  --Robert H. Courtney, Jr.
• At least collectively and over time, even criminals are rational; they will not pay more in the cost of attack than they can expect in the value of success.

Raising the cost of attack is efficient; the cost of attack goes up faster than the cost of the measures to achieve it.  While there is an upper limit, we are nowhere close to it.  The value of success has been going up very fast and the cost of attack has not risen proportionately.  The situation is now urgent and we have some catching up to do.