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

Limitations of One Time Passwords

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

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

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

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

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

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

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

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.  

• Recently the media has reported that, as the result of a gross failure of security at the U.S.  Office of Personnel Management, the service and security records of twenty-seven million Americans have been compromised, likely by a foreign power. The compromise of these records has broken faith with these brave Americans and put them at risk of every thing from credit fraud to coercion, blackmail, and extortion, More recently the reports have noted that these records include the fingerprints of the subjects of the compromised records and have speculated wildly about the risk that result from that.  
• 
  
• The real risk here is not that these fingerprint records can be used for impersonation but that they might be used for identification (for example of covert operatives) (from latent prints). Impersonating someone from a picture of their fingerprints is similar to impersonating them from a photo,of their face. Possession of such an image is useful but far from sufficient. 
  

  
  
• 
  
  • The real risk here is not that these fingerprint records can be used for impersonation but that they might be used for identification (for example of covert operatives) (from latent prints). Impersonating someone from a picture of their fingerprints is similar to impersonating them from a photo,of their face. Possession of such an image is useful but far from sufficient.

    
    

    
    

    2  

    •

    Edit

    •

    Share › 
  • We use four kinds of evidence to authenticate a claim of identity, something only one person knows, e.g., pass-phrase, is, e.g., visage, fingerprint, has i.e., custody, e.g., unique keys, tokens, or can do, e.g. speech, signature dynamics. Since all of these have fundamental limitations, we use them in combination such that one compensates for the limitations of another
• We use four kinof evidence to authenticate a claim of identity, something only one person knows, e.g., pass-phrase, is, e.g., visage, fingerprint, has i.e., custody, e.g., unique keys, tokens, or can do, e.g. speech, signature dynamics. Since all of these have fundamental limitations, we use them in combination such that one compensates for the limitations of another.While it is somewhat counter-intuitive, biometrics are no less limited than the the other three Their fundamental limitation is that they can be copied and fraudulently re-used. We use them more for convenience than security. We use them in combination with other mechanisms in systems of strong authentication.

  Such demonstrations, in and of themselves, do not represent a risk. I am confident that no one is using such an attack against my mobile because I have custody of it. Touch ID, much like the PIN for which it may substitute, is used to resist the fraudulent use of the lost or stolen mobile only for,the short time until its loss is noticed and the phone disabled.

  Note that an attacker only gets five chances to spoof Touch ID and ten to,guess the PIN. Then my mobile erases,itself
  .
• 
  
• For example, while the ability to spoof Touch ID might be useful in gaining access to,the content and capabilities of my mobile, it is far from sufficient. First one must have the phone. While there have been demonstrations of retrieving latent prints using gelatin and using them to fool biometric system, that is an easier problem than trying to go from a paper record.

Strength of Materials

At the  2012 Colloquium on Information System Security Education in Orlando I was repeatedly reminded how much computer security education owes to, and has yet to learn, from engineering education.   

For example, every engineering student takes a course called strength of materials.  In this course, he learns not only the strength of those materials that he is most likely to use but how to measure the strength of novel materials.  The student studies how, and in how many different ways, his materials are likely to fail.  He learns how to design in such a way as to compensate for the limitations of his materials.

A computer science or computer security student can get an advanced degree without ever studying the strength of the components that he uses to build his systems.  It may be obvious that all encryption algorithms are not of the same strength but how about authentication mechanisms, operating systems, database managers, routers, firewalls, and communication protocols?   Is it enough for us to simply know that some are preferred for certain applications?

Courtney's First Law, remember that's the one that says nothing useful can be said about the security of a mechanism except in the context of a specific environment and application.  In this construction, security is analogous to strength, environment to load or stress, and application to the consequence of failure.  Said another way,  environment equates to threat or load and application to requirements. 

Computer science students are taught that their systems are deterministic, that integrity is binary, that security is either one or zero.  On the other hand, William Tompson, Lord Kelvin, cautioned that unless one can measure something, one cannot recognize its presence or its absence.  W. Edwards Deming taught us that if we cannot measure it, we cannot improve it.  

One way to measure the strength of a material is by destructive testing.  The engineer applies work or stress to the material until it breaks and measures the work required to break the material.  Note that different properties of a material may be measured.  The engineer may measure yield, compressive, impact, tensile, fatigue, strain, and deformation strength.  

The strength of a security mechanism can be expressed in terms of the amount of work required to overcome it.   We routinely express the strength of encryption algorithms this way, i.e., the  cost of a brute force or exhaustive attack, but fail to do it for authentication mechanisms where it is equally applicable.  As with engineering materials, security components may be measured for their ability to resist different kinds, for example exhaustive or brute force, denial of service, dictionary, browsing, eavesdropping, spoofing, counterfeiting, asynchronous, of attacks.  While some of these attacks should be measured in "cover time," the minimum time to complete an attack,  most should be measured in cost to the attacker.

There are now a number of ways in the literature for measuring the cost of attack.  The cost used should consider the value or cost to the attacker of such things as work, access, risk of punishment, special knowledge, and time to success.  Since these are fungible, it helps to express them all in dollars.  Of course, we will never know these with the precision that we know how much work it takes to fracture steel, but can measure them well enough to improve our designs.

The Trusted Computer System Evaluation Criteria, The TCSEC, can be viewed as an attempt at expressing the strength of a component composed of hardware and software.  While an evaluation speaks to suitability for a threat environment, with a few exceptions, it does not speak to the work required to overcome resistance.  One exception is in Covert Channel analysis, where the evaluation is expected to speak to the rate at which data might flow via such a channel.  

Because it is often misused, a caution about the TCSEC is necessary.  The TCSEC uses "divisions."  The division in which a component is evaluated is not a measure of its strength.  Many fragile components are evaluated in Division A, while some of our strongest are in D.  In order to understand the strength of a component, to understand how to use it, one must read the evaluation.

We have two kinds of vulnerabilities in our components, fundamental limitations and implementation-induced flaws.  The former are more easily measured than the latter.  On the other hand, it is the implementation-induced that we are spending our resources on.  We are not developing software as well as we do hardware, even as well as we know how.  

The engineers use their knowledge of the strength and limitations of their materials to make design choices.  They use safety factor and margin of safety metrics to improve their designs.  More recently, engineers at MIT's Draper Laboratory have proposed that "complex systems inhabit a 'gray world' of partial failure." Olivier de Weck,  associate professor of aeronautics and astronautics and engineering systems says,

“If you admit ahead of time that the system will spend most of its life in a degraded state, you make different design decisions,” de Weck says. “You can end up with airplanes that look quite different, because you’re really emphasizing robustness over optimality.”

Said another way, systems may be optimized for operation over time rather than at a point in time.  The more difficult it is to determine the state of a system at a point in time, the more applicable this design philosophy.  Thus, we see organizations like NSA designing and operating their systems under the assumption that there are hostile components in them.  

While most of our components are deterministic, none of our systems or applications are; they have multiple people in them, and interact in diverse, complex, and unpredictable ways.  Therefore, designing for degraded state may be more efficient over the life of a system than designing for optimum operation at a point in time.  We should be designing for fault tolerance and resilience.  We should be designing to compensate for the limitations of our materials.  

Of course, I am aware that my audience of information assurance and law enforcement professionals cannot reform computer security education or practice.  I will continue to advance that agenda in other forums.  What I hope for is that you will spend some of your professional development hours, effort, and study on the idea of strength and that it will inform and improve your practice.  It is in part because our education is a work in progress that we are called professionals and are paid the big bucks.

Encryption and National Security versus Liberty

In the 1990s, in what might be called the first battle of the Crypto War, the government classified encryption as a munition and restricted its export.  While opposing export in general, the government was licensing the export of implementations that were restricted to a forty bit key.  Of course, 56 bit was then the norm and, at the time, expensive for the NSA to crack.  

IBM had just purchased Lotus Notes and wanted to,export it.  In order to get a license, they negotiated an agreement under which they would encrypt 16 bits of the 56 bit message key under a public key provided by the government and attach it to the message or object.  This would mean that while the work factor anyone else would be 56 bits, for the government it would be only 40 bits.

Viewed today, 40 bit encryption is trivial; twenty years ago it was strong enough that, while the government could read any message that it wanted to, it could not read every message that it wanted to.  Said another way, it would be able to do intelligence, or even investigation, but it still would not be able to engage in mass surveillance.  

Moreover, we believed that the NSA only collected,traffic that crossed our borders, that it could not be used against citizens.  We believed that the government could keep,their private key secure. Of course, post "warrant-less surveillance," the routine breaches of government computers, including those of the NSA,and the exponential growth of computing power over a generation, this all seems very naive.  

However, I like,to think that it illustrates that it is possible to craft solutions that grant authorized access to the government, with a work factor measured in weeks to months per message, file, device or key, while presenting all,others with a cost of attack measured in decades or even centuries.   

It also illustrates the fundamental, application, and implementation-induced limitations of any such scheme, limitations that would have to be compensated for.  No such scheme will be fool-proof, nor need it be.  Like our other institutions and tools, it need only work well enough for each intended application and environment. 

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.  

Security Culture for the Cloud

It is difficult to miss the trend toward "outsourcing," to have things done by others that traditionally had been done by employees within the enterprise. This trend is facilitated in part by "The Cloud," the Internet and the incredible range of services, fee and free, that are offered on it.

I used the example of Stanford Health Clinic that transferred patient information to a collection agency only to have it posted to a public site on the Internet, a gross and egregious violation of the privacy of their patients.

I left you with the idea that our professionall objective is to arrive at a state in which all parties understand their roles and responsibilities and carry them out in such way as to produce the intended results.

I had decided to elaborate on that advice this week. I came up with a list of policy, technical, and legal guidance for use with out sourcing.

I was going to suggest that enterprises should have a policy that spells out its risk tolerance in general and in regard to the use of outside sources in particular. It might specify which data and applications could be outsourced and which could not. For example, it might specify that the enterprise's intellectual property and personal information should not be outsourced. It might also specify insurance coverage for any risk that exceeds the specified tolerance.

I planned to say that agreements should enumerate the laws, regulations, and contracts to which the parties are subject and all standards that they had adopted. They should also spell out any limitations such as the requirement to disclose information in response to legal service.


I was going to suggest that enterprises should prefer to do business with vendors that were part of such organizations as the Cloud Security Alliance and the Cloud Auditing Data Federation Working Group (CADF). I would have suggested that using enterprises might want to participate in the Cloud Standards Customer Council.

I would have stressed that your contract should provide for audit or for a service auditor report, I would have cautioned you about the limitations of service auditor reports, for example, that they are limited to controls asserted by the auditee and that they are as of the time of the audit.

I had planned to suggest that agreements should be service by service and application by application.

I intended to suggest that agreements should enumerate all existing controls, who is to operate them, and under what conditions. That the agreements should spell out the intended use of the controls as well as what record the use of the controls would produce. Examples of such controls include, Identification, authentication, access control, encryption, administration, provisioning, confirmations, messages, alerts, alarms, measurements, and reports.

I would have emphasized the importance of provisioning controls in The Cloud and pointed out that compromise of those controls might enable others to use services and charge them to you. I had even planned to stress that all use of such controls result in automatic out of band confirmations. I would have given a caution about error-correction and vendor over-ride controls.

Fortunately, while doing my research, and before I had embarrassed myself with all of this irrelevant advice, I came across a report in the New York Times by KEVIN SACK Published: October 5, 2011. Here is part of what I learned.

First, there was no evil here, no recklessness, not even gross negligence, just bad judgment all around. To the extent that there was any motive, it was efficiency, just getting the job done. No greed, no lust, not even sloth.

Stanford Hospital and Clinics (SHC) is a 600 bed general hospital. It is not Kaiser-Permanente or UPMC but it is a major enterprise in its community.

Multi Specialties Collection Service (MSCS) is a collection agency for medical services in the same market as SHC. It bills about $0.5M per year and employees 5-10 people. One might call the relationship asymmetric, one-sided.

The identity and role of the sender of the information is not public, but should have required significant management discretion and rare privileges to access and send it.

The receiver of the information was a contractor to MSCS. He often represented himself as an officer of MSCS and had an MSCS e-mail address. Been there, done that. He decrypted the data, put it in a spread sheet, and, among other things, gave it to an applicant for a job with him.
While SHC says the information was for "permissible hospital billing support purposes," the consultant says that it was for a "study." In any case, the information was not passed in the normal course of "collections," the service. I believe that both the sending and receiving of the information probably was outside the agreement between SHC and MSCS.

The actual posting to the public web-site, StudentofFortune.com, was by a job applicant to the consultant. He had given the applicant the spreadsheet to convert it to charts and graphics as a test of skill

The posting was a violation of the SoF Terms of Use which require the user to "represent and warrant that (they) (a) own or have sufficient rights to post (their) Contributions, on or through the Site, and (b) will not post Contributions that violate Student of Fortune or any other person’s privacy rights, publicity rights, copyrights or contract rights.

Two things seem clear. First, everyone involved has egg on their face except StudentofFortune.com. Their Terms of Use were obvious, concise, plain, and clear. One cannot register for their site without acknowledging and agreeing to them. When the violation was called to their attention they responded on a timely basis. I would gladly testify for or against any of the other parties.

Second, none of the policy, technical, or legal measures that I wanted to recommend would have prevented the breach. If asked in advance, management might well have accepted the risk that so many controls and people would fail at once, However, SHC is now the target of a $20M class action law suit and will almost certainly be penalized by the regulators. MSCS has lost a major client, has closed its web site, and is not answering its phone.

I am not sure that the penalties fit the crime but they sure are getting our attention However, to the extent that the breach impedes the urgent move to electronic health records, or even the efficient use of cloud resources, perhaps they are proportional.

I like to think that my lists above are useful, if not necessary, but they are clearly not sufficient or even the place to start. No, we are back to management and security 101. There is no substitute for training and supervision.

"Outsourcing" makes this even more important. Note that StudentofFortune.com is typical of free or low-cost collaboration "cloud services" that help our employees get their jobs done and are within the discretion of most of our employees. We are going through a major change in how we organize production and resources. It is being driven by the falling cost of information technology. As this new model matures we need to evolve a culture of personal due care, one in which people automatically ask "should I do it" rather than simply "Is it efficient?" A culture in which people automatically consult with others before they act, a culture of caution.

Security must start with our most effective controls, training and supervision. We should focus on or use our other tools only to the extent that they are more efficient. Then we will be called professionals and be paid the big bucks.

Artificial Intelligence

This blog post is a work in progress.  Comments are solicited.  It is an attempt to bring my seventy years of experience in using, governing, managing, and securing innovations in computing technology to the issue of "artificial" intelligence.

In 1956, I was part of the first generation of computer user/programmers.  We stood on the shoulders of the giants that I call generation zero, Turing, Flowers, Shannon, Aiken, Eckert, Mauchly, von Neuman, Hopper, et. al.   

We had to tell the computer exactly how to arrive at the result that we wanted.  We expressed the computations that we wanted in terms of the operation codes of the hardware.  Almost all computers had op codes for add, some could subtract. The powerful ones even had operations for multiply and divide.  However, even those did multiplication by iterative addition and division by iterative subtraction.  We called that programming.  Those of us who could describe how to achieve a result by such tiny steps were called programmers.

In the mid fifties, one might create a program on a blackboard, flip-chart, or yellow pad.  We would transcribe the program into punched paper cards or tape that could  be eletro-mechanically "read" by and into the storage of the computer.  The paper and the reader were our user input mechanism, our application programming interface, our API.  We would enter the program first, followed by the data, also in punched paper.  The process was so expensive that the results had to be very valuable in order for the process to be efficient.  

While in the early days, I operated the computer, within a decade users and programmers had pretty much been excluded from the "computer room" and the role of operator had become specialized.  Within another decade the computer terminal was the common user interface. In 1981 the IBM personal computer had a key-board and a CRT that could display 80 columns by 25 lines of green alpha-numeric characters.  Like the terminals, it provided what we now think of as a command line interface.  Three years later the Apple Macintosh had a  graphical user interface (GUI) with a mouse.  Two years later came Windows.  "Point and click" was now part of how one used a computer. 

As computers have become more powerful and cheaper, much of that improved power has gone into the user interface, into making them easier to use.  Early examples include high level languages, like Fortran and Cobol, and interpreters like APL and Basic

Today's input and output devices include touch screens, cameras, microphones, ear phones, speakers, and environment and application sensors and controls. Modern computers can talk, listen, and recognize and process images.  We have smart appliances, homes, vehicles, drones, agents,  and robots.  I can testify that in1956 some of these were almost beyond imagining.

Games have always been part of computing and a measure of computer program "intelligence."  In 1956, my colleague, Dick Casey, and I wrote a program to teach the IBM 650, using console switches and lights for i/0, to play Tic-Tac-Toe.  My  mentor, Dr. Albert Samuels, wrote a program for the IBM 701 to "learn" to play checkers.  It got really serious in 1997 when IBM's Deep Blue defeated chess champion, Gary Kasparov in a six game match.  On February 16, 2011 IBM's Watson defeated champions Ken Jennings and Brad Rutter at the TV Show Game, Jeopardy.  

In 2015, Google's Alpha defeated European champion Fan Hui 5-0. Its most famous victory was against world champion Lee Sedol in 2016, winning the series 4-1.  Alphagozero "taught" itself the game.  

In November 2022 OpenAI introduced ChatGPT and demonstrated its ability to converse in natural language.  Using text-to-speech and speech recognition, it can even talk and listen.  It was to be the first of many large language models (LLMs), the latest user interface to the computer.  However, the ability of these chat bots to communicate in natural language hides the huge data sets, the enormous computing power, and the complexity involved.  It caused many people to invest them with the personality and autonomy that they merely mimic.

Using these programs one no longer has to provide the computer with a program, the steps to create the result.  One need merely describe the result, "prompt" the computer and it "figures out" how to arrive at it.  If the prompt is ambiguous, the computer may, in natural language, ask the user for addtitional information. The "Model" instantiates both the capabilities and the limitations of the program.  

We call the model "large" because it includes a huge amount of data, so much that it all but defies human comprehension.  Indeed it can solve difficult problems in conversational time.  However, it is correct to think of it as fast "table lookup" in a big table, using so much  computing power and energy that it is just now becoming efficient.  

The LLM organizes its data to optimize its use; we call the data "training" and the organization "learning," expressions that we analogize from human intelligence.  Therefore, the "model" instantiates both the capabilities and limitations of the program and its data.  

In part, because of the complexity, training, and the lack of precision of the natural language used in the prompts, what we want the computer to do, the results are sometimes not what the user intends and expects.  Said another way, in spite of its capabilities, artificial intelligence may be no less error prone than natural intelligence.  Sometimes the results are so far from the user's intention, again by analogy to the natural, the computer is said to "hallucinate."  Therefore, it is best to restrict the use of AI to the set of problems where, while we might not be able to arrive at the results by ourselves we can easily  check the result.  For example, while one might not be able to compute the cube root of a large integer, we can recognize it when we see it.  

Nothing useful can be said about the security of any mechanism except in the context of a specific application and environment.  --Robert H. Courtney, his first law.  

Some human being or enterprise is responsible for everything a computer is asked to do and for all the properties and uses of the result.  

 The responsibility of both individuals and enterprises for the application and use of a computer, specifically to include those applications that use natural language and mimic people, includes compliance with law, regulation, contract, morality standards, and prudence.  

As with anything else, an individual exercises her responsibility by complying with the law, regulation, contract, ethics, use of appropriate tools, and due care.  This requires knowledge, skill, ability, experience, and good judgement.  One starts by ensuring that one meets the applicable requirements.   One ends by doing nothing rather than doing the wrong thing.  

An enterprise exercises its responsibility by policy and governance, i.e., what it authorizes its agents to do and tells them not to do.  Management must use all available controls including, but not limited to:

• Direction
• Training
• Assignment of duties, roles, responsibility, limits, discretion, and authority
• Supervision
• Multi-party controls
• Automation
• Budget
• Recognition and respect
• Compensation
• Disciplinary action 

to ensure that its intentions are met.

One of the things that policy must do is to express managements risk tolerance in such a way that all managers and professionals at all levels understand what that means that they should do.  For example, the management of a mature enterprise might say such things as "Novel technology must be applied in a cautious, conservative manner,"  "line of business managers (not IT) must authorize and budget for the application of novel technology," "application of novel technology must be initiated, authorized, and budgeted for by two or more levels of line of business management," or "novel technology should be exploited and applied consistent with normal business risk."

Alternatively, the management of a high business risk start-up might say "novel technology should be aggressively applied and exploited in pursuit of business opportunity."  Needless to say, that this author recommends the more conservative approach for most enterprises.  

Recommendations

Things you Should be Doing Anyway

Use strong Authentication: Use at least two kinds of evidence, (shared secret, possession, biometric, or behavior). At least one form of which is resistant to replay; e.g. one-time password (OTP), biometric with liveness test.   Internet facing applications, mission critical applications, on management and administrative controls, and everywhere else, in that order.  This is the most efficient of all measures.  Nothing else will give you as much protection for dollar expended.  Consider Passkeys, one time passwords from hardware tokens, software tokens, e-mail, or SMS messages, in decreasing order of strength.  Consider offering users a choice of methods for their convenience.  

Structure your network and layer your defenses.  Start by isolating high risk Internet facing applications, e.g., e-mail, browsing, and messaging from internal enterprise applications, from mission critical applications, from administrative and management controls, from servers, e.g. database, file, communications, from storage devices.  

Employee "Least Privilege" access control.  Individuals and processes should enjoy only those capabilities and privileges that are required to fulfill their assigned roles.

Restrict "write" access.  In order to preserve accountability, "write" access to any object should be restricted to a single individual or process, e.g., application, database manager.  If you employ the common risky practice of granting everyone "read/write," changing to this policy will involve some administrative effort and may encounter some user resistance.  However, it will reduce insider risk.   

Employ "zero trust."  Zero Trust can be thought of a special case of least privilege in which every connection between processes is authenticated in both directions, both vertically and horizontally.  For example, users and applications mutually authenticate one another. Applications authenticate the database manager, the database manager authenticates the file system and vice versa.  This policy can often be implemented using existing controls.

Use multi-party controls.  Assign duties and responsibilities in such a way that agents, simply by doing their jobs, act as checks upon one another and that two or more must act in concert for material acts. 

Monitor and log all activity.  Monitor and log both the traffic that passes a firewall and the traffic that is rejected.  Changes in traffic patterns may be evidence of an attack.  

These policies and controls can greatly increase the cost and time-to-success of attacks.  They are efficient, that is their cost is small, usually justified by the reduction in the cost of the risk that they mitigate.  They are both essential and efficient.  

As we have noted, large language models (LLMs) increase both risk and opportunity.  Several LLM builders have demonstrated the ability to efficiently discover large numbers of vulnerabilities in operating systems and browser.  These models can demonstrate how to exploit the vulnerabilities that they discover.  They should also be able to remediate them.  

In the next sections we will make recommendations to reduce the risk and safely exploit the opportunities. 

Use LLMs Conservatively.  Prefer low-risk applications, applications where the quality of the results are obvious, applications that are tolerant of error.  Choose vendors and products based upon experience and support; do not rely upon claims.  

Train with Application Specific Data.  Prefer to train LLMs with data that is curated and specific to the purpose.  

Over Control New Applications.  Err on the side of over controlling any new application, including all uses of LLMs. As the application matures, one can always relax controls.  However, if an application gets out of control, merely tightening the screws will not bring it back into control. 

Use AI in Development. Use LLMs for coding and testing, including detection and  elimination of vulnerabilities.  Apply AI to Network Monitoring.  As attacks increase in rate, human monitoring will be less effective and efficient.  Use AI to support incident analysis and remediation.  

Use AI to vet New Products and Changes.  The software supply chain is under attack and is becoming the preferred way to distribute malicious code.  The response of suppliers has been Caveat Emptor.  Use AI to "beware."

Restrict the use of Enterprise Data.  Expose enterprise data only to enterprise AI, never to public or cloud applications.  

Consider the use of AI to automate "patching."  Expect automation to be necessary to maintain software at the rate at which AI will discover vulnerabilities.   

On Understanding Biometrics

A decade or so ago, I had an extended dialogue with David Clark, of the Clark-Wilson Model, about biometrics. He knew that the remedy for a compromised password was to change it. Since he knew that biometrics could not be changed, he could only understand how they worked for about fifteen minutes at a time, about the same length time that I can understand the derivation of an RSA key-pair.

Unlike Passwords, biometrics do not rely upon secrecy, they do not have to be changed simply because they are disclosed. Biometrics work because, and only to the extent that, they are difficult to counterfeit.

We have all heard about the attacker who picked up a latent fingerprint in gelatin and replayed it, or the image scanner that was fooled by a photo. Good biometric systems must be engineered to resist such attacks.  For example, Google has patented a (challenge-response) scheme to resist replay in a facial recognition system by directing the user to assume one of several expressions that the system has been trained to recognize.  

While the fundamental vulnerability of passwords are replay and disclosure, the fundamental vulnerabilities of biometrics are replay and counterfeiting. These vulnerabilities are limitations on the effectiveness of the mechanism, rather than fatal flaws. What we must ask of any biometric system is how does it resist replay and counterfeiting.

At a recent NY Infragard meeting there was discussion of biometrics that illustrated that this confusion persists. In this case, at least one person seemed to be convinced that the secrecy of the stored reference had to be maintained in order to preserve the integrity of the system.

As with properly stored passwords, one cannot go from the stored reference to what one must enter. We solved the problem of disclosure of the password reference by encrypting it with a one-way transform at password choice time. (in practice, all too many passwords are stored in a reversible form.) At verification time we apply the same transform to the offered password and compare the encrypted versions. By definition of "one-way transform," it is not possible to go from the stored reference to the clear password.

We do not store an image of the face, the password, or a recording of the voice. Instead we store a one-way, but reproducible, transform. To make sure that the transform is reproducible, we may collect multiple samples so that we can test for reproducibility.

However, as with passwords, biometrics are vulnerable to replay attacks. While we cannot discover the biometric from the reference, we might capture an offered instance and replay it over and over.

Like passwords, biometrics may be vulnerable to brute force attacks, but unlike passwords, they are not vulnerable to exhaustive attack, if only because it is impossible to try every possibility. While a password reference can be stored in 8 or 16 bytes, a biometric reference may be hundreds or low thousands of bytes.  In an exhaustive attack against a password, each unsuccessful trial reduces the uncertainty about the correct answer, in part because we know the max size. This may not be true about a brute force attack against a biometric where the maximum size may be arbitrary.

For most purposes we use brute force and exhaustive as though they were synonymous but they really are not. In brute force, we submit a sufficient number or trials to succeed in finding a (false) positive. An exhaustive attack is a special case of a brute force attack in which we are trying to find one integer in a known set. While the reference for a biometric may be too large to be exhausted but there are many values that will fit.

This introduces the issue of false positives. There is only one password that will satisfy the transform, it is at least one integer value away from those that do not satisfy. We key in the integer. However, we "sample" a biometric; there will be many biometric samples that will fit. Depending upon the precision of our system, it might even be possible to dupe the system, a false positive. On the other hand, it is also possible for a given sample of a valid biometric to be rejected, a false negative.

Biometric systems can be tuned so that they achieve an arbitrary level of security; we are looking for a transform that minimizes both false positives and false negatives. Unfortunately we reduce one at the expense of increasing the other. That is to say, the less likely it is for the system to permit a false positive, the more likely it is to generate a false reject. We tune the mechanism to achieve an acceptable ratio of on to the other for a particular application and environment.

My preferred biometrics are the visage, i.e., the face, and the voice. These share the advantage that they can be reconciled both by a computer and by non-expert human beings. Infants can recognize their parents, by face and voice, by the age of six months; it has survival value. Many share the experience of recognizing someone, that we have not seen in years, from one or two words, spoken over the telephone.

Until very recently, machines could not reconcile faces as fast humans, indeed fast enough for many applications. However, Google now has software that can not only authenticate an individual from an arbitrary image but identify them within seconds.

For most of the time that they have been in use, fingerprints could only be reconciled by an "expert," but we now have computers that can do it even better than the experts. In fact, recent studies using these computers have suggested that even these experts are all too fallible. Nonetheless, non-experts can independently verify fingerprint identification.

Think about DNA. While it discriminates well, it contains so much information that it takes a long time to reconcile and the results cannot be independently verified by amateurs. To some extent we will always be dependent upon instruments and experts.

Since biometrics share a vulnerability with passwords to replay, a password plus a biometric does not qualify as "strong authentication." Therefore, the preferred role of biometrics is either as an identifier or as an additional form of evidence in a system of strong authentication, one in which another mechanism, e.g., a smart token, is used to resist replay.
Because there is only a vanishingly small chance that two samples of a biometric will be identical, any sample that matches one previously submitted could be thrown out as a possible replay.

Part of the special knowledge that identifies us as security professionals, and for which we are paid the big bucks, is that knowledge about the use, strengths, and limitations of biometrics.