Artificial Intelligence

Artificial intelligence, AI, is a new user interface to the computer.  Large language models (LLMs) make the computer easier to use.  They permit us to describe the result that we want in natural language. improving productivity and enabling new applications.  AI will improve intellectual productivity as much as the internal combustion did for manual productivity.  In response to internal combustion, and more specifically the tractor,  we shortened the work week from 72 hours to 44 and invented vacations and retirement.  In the process, we killed off two generations of young men and still suffered 25% unemployment.  Said another way, increases in productivity are disruptive.  

The computer, with or without AI, is a tool.  Tools vary in quality, utility, usability, and use.  The user is responsible for the selection of the tool, the purpose to which it is put, and for all the properties of the result.  This is true whether the user is an individual or a group.  An enterprise must be responsible and accountable for everything that results from its application of this powerful technology. We call this security and we forget any part of it at our peril. We must not impute authority or autonomy to the tool; we must not anthropomorphize the tool.  "The craftsman does not blame his tools."  We must hold people accountable for how we use this powerful new tool.  

In the near term we should focus on embedded application specific implementations of AI.  We should follow the example of IBM, a pioneer in the field.  IBM trains the engine, think Watson, on application specific curated data; they build in governance and transparency from the ground up.

Public policy must soften the impact of the disruption.  This will include shortening the work week to spread the work and the leisure.  It should include a guaranteed minimum income to ease transition from old jobs and skills to new ones.  Finally, it should include changes in tax policy from labor to capital, people to robots, and production to consumption, to more securely and equitably finance the social safety net.  

Common System Design Flaws

I recently came upon https://tinyurl.com/SystemDesignFlaws It was written as a chapter of the Handbook of Information Security 2001.  I offer the link to any who would like to see the whole paper but recap the flaws and the recommendations for avoiding them here.

The flaws covered by name are:

• Complexity

• Incomplete Parameter Checking

• Incomplete Error Handling

• Ineffective Binding

• Inadequate Granularity of Controls

• Gratuitous Functionality

• Escape Mechanisms

• Excessive Privilege

• Failure to a Privileged State

• Unsafe Defaults

• Excessive Reliance on Application Controls

• Others

Examples and illustrations of these common flaws are discussed at length in the paper.  

The following recommendation should be considered when crafting and staging applications. By adhering to these recommendations the programmer and the application manager may avoid many of the errors outlined in this chapter.

• Enforce all restrictions upon which you rely. 

• Check and restrict all input parameters to the intended length and code type. 

• Prefer short and simple programs and program modules. 

• Prefer programs with only one entry point at the top or beginning and only one exit at the bottom or end. 

• Prefer reliance upon well-tested common routines for both parameter checking and error correction. Consider the use of routines supplied with the database client. Parameter checking and error correcting code is difficult to design, write, and test. It is best assigned to master programmers. 

• Fail applications to the safest possible state. Prefer failing multi-user applications to a halt or to logon rather than to a new instance of the application or the environment (e.g., operating system). 

• Limit applications to the least possible privileges. Prefer the privileges of the user. Otherwise, use a limited profile created and used only for the purpose. Never grant an application system-wide privileges. (Since the programmer cannot anticipate the environment in which the application may run 

and the system manager may not understand the risks, exceptions to this rule are extremely dangerous.)

• Bind applications end-to-end to resist control bypass. Prefer trusted single system environment. Otherwise use a trusted path (e.g., dedicated local connection, end-to-end encryption, or a carefully crafted combination of the two).  Include in an application user’s privileges only that functionality that is essential to their use of the application. Consider dividing the application into multiple objects requiring separate authorization so as to facilitate involving multiple users in sensitive duties.

• Controls should default to safe settings. Where the controls are complex or interact in subtle ways, provide scripts (“wizards”), or profiles.

• Prefer localized controls close to the data, e.g., prefer file system to application, database manager to file system.  Prefer authentication of users (or using processes) close to the user (e.g., on the mobile client.)

• Use cryptographic techniques (e.g.,digital signatures) to verify the integrity of the code and to resist bypass of the controls. 

• Prefer applications and other programs from known and trusted sources in tamper-evident packaging. 

Cyber Resilience

https://tinyurl.com/yc6s5sdt

Mr. Basu's observations are at odds with mine.   If enterprise was more focused on prevention, than for example on insurance, we would not have the successful extortion industry that we see today.  

In the early days of IT we called the security measure of last resort, "backup and recovery."  It focused primarily on human error and disasters, limited to a data center or an enterprise.  As the technology matured and we became increasingly dependent on IT, we called it "business continuity."  It focused on running the business in the face of both natural and man-made risks.  

Today, when our entire infrastructure is dependent upon vulnerable, not to say fragile, interconnected systems of energy, communication, and finance, we call it "resilience."  It focuses on "Black Sky" events.  The risk is to "national security," not to say survival.  

While I grant Mr. Basu the importance of resilience, I suggest that the most efficient way to achieve it is by prevention, by dramatically improving the quality and robustness of our systems.  We need to increase their resistance to both natural events and malicious attacks by a decimal order of magnitude.  Fortunately for us, doing so, both individually and collectively, is efficient.   

We know what to do:

• Strong Authentication
• Least Privilege Access Control
• Process-to-Process Isolation, logging, and authentication
• Structured Network
• Application Layer End-to-End Encryption
• Privileged Access Management
• Redundancy
• Data, Application, System, Network, and Enterprise Persistence, Continuity, and Recovery
• Law Enforcement
• Other

We lack the vision, the intention, and the will.

  

 

Digital Credentials

The Organization for Economic Co-operation and Development (OECD) is seeking feedback on a recently published draft of guidelines for digital credentials.  The guidelines are intended to make digital credentials widely acceptable and accepted, even across national borders, for example a digital passport.  https://www.nfcw.com/2023/03/28/382786/oecd-seeks-feedback-on-digital-identity-recommendations/

Let me start by noting that this is not a proposal for a single or national credential.  I have always feared such a credential because it could be used by an authoritarian regime to control, or even restrict, rights to, for example, work, travel, healthcare, education, or food, clothing, and shelter.  Rather, I have always preferred a pluralistic system with multiple issuing authorities, granting different, if limited, privileges and employing different criteria for the granting of the credential.  

In today's world, if one wants to recognize and authenticate a stranger, one might well use a drivers license, issued by the state in which the person resides and including an image, date of birth, and a name and address, and a credit card issued by a bank.  Two credentials issued by different authorities in the same name.  Similarly, one might use drivers license and a passport.  

For example, in my Apple digital wallet I have ten different credentials issued by ten different authorities.  Most are merely digital copies of physical credentials. All of these can be identified visually, though some relevant information may be hidden for reasons of security and privacy.  For example, on debit and credit cards, part of the Primary Account Number (PAN) may be hidden.  Most can be read digitally by means of NFC and/or QR tags.  

At the time of this writing, residents of three states can include their drivers license in their Apple Wallet.  Three more states issue their own electronic licenses.  Note that a policeman presented with an electronic license will be able to automatically verify it, check its currency, and check for any outstanding "wants or warrants," in real time.  

In a different "wallet app" I have nine digital images, front and back, of card credentials only one of which is also in my Apple Wallet.  These credentials can only be read visually but nothing is hidden.  

In a folder in DropBox I have digital images of twenty credential documents issued to me by various authorities beginning with my birth certificate, and including my social security card, my high school diploma, my college degree, my record of military service, and my passport.  While any one of these might be a forgery or fraudulently obtained, collectively they reliably document everything significant about my identity.  Of course, the only identifying information that all these documents share in common is my name.

These documents are recorded in the Portable Document Format, that is as PDFs.  A PDF file, I.S.O. Standard 32000, preserves text, fonts, format, vector graphics, raster images, color, and even discoloration, all properties of the original useful in authenticating the copy and resisting forgery,  Even the Internal Revenue Service (IRS) accepts PDFs as authentic.  

Which brings up the issue of a unique identifier.   A few of us enjoy a unique name, one that we share with no one else, but most of us share even our full name with others.  This is the problem which the Social Security Number solved.  Modern information technology does not need it to uniquely identify us but it remains useful as tie breaker when other identifiers result in a collision.  

What and how much information does it take to uniquely identify us.  First our name, place of birth, and date of birth, uniquely identifies us.  No one else born on your birthday in the same place as you were was given the same name as you.  Similarly, name and address are unique; no one else with your full name lives where you do.  While there were a few errors of assignment in the early days, the ten digits of the SSN are sufficient, not only to give one to each of  us but also to include a little information about where it was assigned.  Though collisions are possible, it is likely that there is no one else living in your postal code with the same birth date as you.  Similarly the last four digits of your SSN will distinguish you from all those others that might share your name.  

Now if you clicked on the link at the start of this post, you know the properties of electronic credentials that the OECD thinks are valuable.  I have a different list.  By definition they are for paperless credentials.  

One starts with wanting the credentials to be readable, first visually but also electronically.  Visually because that is how we have always reconciled credentials and electronically for convenience in exchange with those who wish to rely on or verify the credential.  Most mobile computers, i.e., phones, can read a QR tag.  A tag might contain the unique number of the credential, for example a license number or account number, or it might contain a link (URL) to a copy of the credential.  

One would want the credential to be portable across wallets or devices.  This might be by means of purpose built apps or by more general and flexible capabilities such as URLs, SMS or e-mail.  Many digital objects have a "share" button to make portability both convenient and flexible. One might want a copy on paper, a desktop or laptop, a digital wallet, "wearables" like watches or rings, or in the cloud.  Similarly one would like the credential to be authentic and easily verified.  Note that one accepting a digital credential may be interested in both its currency as well as authenticity; online realtime access to the issuers database will always be useful and in some applications necessary.  

We are very close.  Form, use, and acceptance are becoming routine.  I have paid for dinner with my American Express Card by clicking on a QR tag on the check.  I have also paid with the image of my card in the wallet on my iPhone, giving the iPhone to the waiter just as I would have given the physical card.  The image of the card was accepted without question or comment.  Similarly, I voted using the image of my drivers license, again accepted without question or comment.  I recently boarded a train using an electronic ticket.  The ticket included a QR tag to be read by the conductor's mobile.  It demonstrated that I had a reservation and had paid for a particular seat on a specific train.  While I might have printed out a paper copy, and some travelers were using one, the conductor checked all using the QR tag, paper or digital.  

The key to all of this is reliable, routine, convenient, and universal acceptance.  Note that in the example scenarios above, one might have been embarrassed if the digital credential had not been accepted.  We need maturity and standards, to include those that we already have like PDF, QR, NCF, and SMS, as well as such as those proposed by the OECD.

Finally, a word about privacy and security.  Trust and acceptance will rely at least in part upon those mechanisms that resist both forgery and misuse as well as those that resist application fraud.  

While the PDF standard preserves many of the properties that resisted forgery in the traditional credentials, they do not preserve them all.  For example, it does not preserve texture and materials such as we use to resist counterfeit currency.  On the other hand, digital implementations give us the ability to use cryptographic mechanisms such as hashes and digital signatures.  We already have experience using these mechanisms in such applications as code signing and digital currency.  While in the early applications, so far we have not seen instances of forgery, we know how to address them should the properties preserved by the PDF standard prove inadequate.  

We will resist misuse by controlling access to the credentials using secure digital wallets, strong authentication, and biometrics.  To misuse the copies of my American Express one must first possess the copies and meet any conditions for their use such as biometrics or PINs implemented in the device in which they are stored, e.g., mobile phone or cloud storage.  We can also lock the credential to the device so as to resist "screen scraping."  

Finally, trust in credentials, digital or otherwise, will depend in part upon the issuing authority, representations made by the authority, and the rigor with which the authority issues the credential.  Having already told you more about this subject than you likely wanted to know and more than I intended when I began to write, I will defer that discussion to a later post.

Check Fraud?

 I recently saw a great video https://www.bankinfosecurity.com/how-to-fight-check-fraud-look-beyond-technology-a-21299?rf=2023-02-27_ENEWS_SUB_BIS__Slot1_ART21299&mkt_tok=MDUxLVpYSS0yMzcAAAGKMqJfI2i87GCnqQPTeoRoYMCf1EEHC1AJ4qh708AIYOhT0Q8JFA_5fWC2pELiMEUqWwUPXl7I0l13QQJQKJapHyHw3oF_eWabtx5ta8nuZ8aR4A by Karen Boyer, Sr. VP of M&T Bank on how to fight check fraud, a topic that I recently addressed.   However, the problem that she addressed was not so much "check fraud" as frauds involving checks.  

I see two different problems here, and faster reversibility is not addressing either. First is stolen legitimate checks deposited to fraudulent accounts. This is a classic "know your customer" problem. This problem is aggravated by the banks' desire for new accounts and initial deposits. One can set up an account, deposit a stolen check to it, and transfer or withdraw the funds, all without ever having gotten close to a bank officer or even a human, non-automated, decision.

The second is alteration, amount or payee, of an otherwise legitimate check before deposit to a fraudulent account. "Know your customer," positive pay, and online banking all apply here. (I no longer have to wait for a statement in the mail to recognize fraudulent activity to my account, as I did seventy years ago when I first began to write checks. I can see it daily.)

All that said, these powerful controls no longer appear to be sufficient. The demand deposit system used to have, and relied upon, controls to ensure that banks only did business with people and institutions from whom they knew they could recover. In the name of popular banking and fast availability of funds, many of those controls have been watered down.  

Ms. Boyer cautions banks to "monitor accounts."  I encourage depositors to use online banking to do the same.  While the depositor is not responsible for fraud, someone has to recognize it, the earlier the better.

When I think up a solution, I will get back to you.

Apologia

 As of March 15, 2023 I will no longer be associated with InfraGard.  The FBI has set conditions for continued association that I am not willing to meet.  It behooves me to explain my position.  

The InfraGard web site was recently compromised.  The FBI has been less than forthcoming about the compromise but they have admitted that personal data of their constituents, including e-mail addresses and employment, have been compromised.  They have not offered any compensation or remedies to said constituents.

As a matter of policy I do not do business with management in which I have lost confidence.  Specifically I do not continue to use web sites that have proven unable to protect my personal data.  The FBI has made it a condition of continued InfraGard membership that members must routinely use the compromised web site and that they do so no later than March 15, 2023.  I will not meet that condition.

More over the FBI requires that members provide additional personal data to the web site so that they can reverify one's identity and conduct a criminal background check.  There can be only two reasons for such procedures.  First Colonel Blimp is once more covering his derriere.  Second, he has lost confidence in the database, believes it to be contaminated with fraudulent entries. If they do not trust it, I certainly do not.  

They have announced that they intend to turn personal information over to a third party for authentication.  Not only do they expect me to trust the management that has already demonstrated that they cannot protect my data, they expect me to trust an additional unnamed party, a party that is already in the data collection and exploitation business. I have no interest in improving the quality of their data.  

Most of you are far too young to remember the House UnAmerican Activities Committee and their actions.  Careers were destroyed.  One of the things that we learned from their proceedings was that mere friendship, association, was sufficient to create a presumption of guilt and to place the burden of proof on the accused.  If the InfraGard database disclosed nothing else, it disclosed associations.  (I would not want my e-mail used to query a (just for example, the NSA) database.  None of us is  more than six degrees of separation from a foreigner, terrorist, or criminal.  The three degrees of association that the authorities will admit to might implicate hundreds of thousands.)   

It is clear that we, the FBI and I, no longer enjoy mutual trust.  However they expect me to reestablish my bona fides before they have demonstrated theirs.  It was not I that failed and created this situation.  Given the rather one-sided relationship between the FBI and their InfraGard constituency, it does not surprise me that they want the constituents to bear the cost of remediating their database.

I am late into my ninth decade.  My continued association with InfraGard is limited at best.  Moreover, I enjoy mutual trust with a large number of colleagues, trust that preceded the founding of InfraGard.  I do not expect others to follow my example but I did think it useful for me  to give warning and share my reasoning.  

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.