Notes for my Capstone Address at the 2026 New York Metro Joint Cyber Security Conference

 Thanks to our speakers.  Their presentations were thoughtful, useful, and well communicated.

World order is deteriorating, in large part because of a failure of US leadership.  Our historic allies are now afraid to rely on us.  

Kinetic warfare is now automated, persistent, and continuous; while the scale is smaller than the great wars of history, we are killing a thousand civilians for every soldier.

The application of AI to vulnerability detection has demonstrated unequivacably what I have long asserted:  our software sucks and our insfrastructure is so fragile as to constitute an existential risk.  

We need strong authentication for applications, clients, services, devices, and users.  I like passkeys for security and convenience.  All authentication schemes are limited by the security of the end points.  

The single most talked about application for quantum computing is cryptanalysis.  Google speculates that by 2030 we may be able to solve for a private RSA key, from a cryptogram and the public key, in hours.  During any hour we generate thousands of RSA key pairs.

We have always cautioned against sharing of IDs and passwords.  The IDs most likely to be shared are privileged.  Privileged Access Management is an application and there is great software for it.  

A human individual or enterprise is, and must be held, responsible for everything that a computer is asked to do.  For AI they are responsible for the training, goals, data, weights, and, prompts.  They are responsible for all the results, i.e. action, uses, and properties including accuracy, correctness, and purpose.

The responsibility must include criminal or civil accountability.  Consider OpenAIs  attack against Hugging Face. Open AI lacked Mens Rea so they were not criminally liable.  However, they were reckless and therefore they are civilly liable for any and all damage that their experiment caused.  It is essential that they not be allowed to escape that responsibility.  I am encouraged that the state of California is suing Open AI.  However, they have the burden of proving standing and damages.  I wish Hugging face, the immediate victim, would join the suit.  We must limit criminal and reckless use of what is only a tool. 

We worry about AI going rogue but that is not the problem.  The problem is what someone or some enterprise asked the AI to do and what precautions they took.  It is clear that we are not very good at that.  If we want to enjoy the benefits of AI while avoiding unintended consequences we must hold each other scrupulously accountable for its uses.  

We should restrict the use of LLMs to applications where we can predict, evaluate, and control the results. I continue to recommend IBM's stated approach: application specific uses, curated, application training data, and transparency and governance built in from the ground up.  I like the approaches of Apple Siri and Microsoft Co-pilot, that use AI to assist with specific tasks in a known context.   

Be careful what you ask for!   Most of our problems in AI are rooted  in the limitations of natural language and are peculiar to LLMs.  Much of the increase in productivity will come from other models.

AI is goal seeking; you must express both goals and limitations.   So, do not think, or even talk AI.  Think productivity, applications, use cases, and tools.

Two presentations dealt with leadership.  

There is no budget fairy.  Those who have budget, asked for it.  They were often told no.  They were undeterred.  They redid their proposal and justification and asked again, as many times as required.  

Incidentally, those with budget are the same one's that are getting promoted.  Management loves those who tell them how to spend in such a way as to decrease risk and improve profits.  

Continuous Third Party Risk Management (TPCRM) can be viewed like an application, a measurement system.  Science and technology advance with our ability to measure.  William Thompson, Lord Kelvin, taught us that if you cannot measure it, you cannot recognize its presence or its absence.  W.  Edwards Demming taught us that if you cannot measure it, you cannot improve it.  Security is the job of the business units; the job of the security staff includes continuous measurement.  Evidence.  

The responsibility for the protection of an asset rests with the executive or manager who exercises the enterprise's ownership rights in the asset, the line of business executive.  Not the staff executive.  Because each is achieved at the expense of the other, one cannot separate the right to use from the responsibility to protect.  

Staff is about goals, measurement and monitoring, methods, tools, and operation.

One use of policy is to express the enterprise's risk tolerance in such a way that all executives and manager's understand their responsibility and how they are to behave.   

Fraudulent e-mails authorizing payments (BEC)mand billion dollar digital currency thefts demonstrate the need for multi-party controls and out-of-band confirmations of all changes and transactions.  

I had been teaching and writing on personnel controls, supervision, training, job rotation, mandatory vacation, compensation, etc. for a decade I before learned the two most important ones, please and thank you.   

Special thanks to our Chairman.  "If you want a job well done, give it to a busy man."  If you want it especially well done, give it to John Checco.  

Be Careful what you ask for...

Bruce Schneier cautions us that Large Language Models LLMs are very literal in their interpretation of what they are asked to do.  They are very good at interpreting the words and very poor at divining or understanding the intent or meaning.  Midas wanted gold but got the Golden Touch.  Sissa ben Dahir wanted a big reward for inventing chess but he really did not intend to destroy the world.  

One problem in large language models (LLMs) is the use of human language to specify the goals.  Bruce, and his colleague, Barath Raghavan, speak of the genie coefficient, the gap between what a user intends and how the AI interprets it.  The proper interpretation of human language relies upon context.  "If you ask  someone to 'get coffee,' they bring you a cup, not a plantation."  

Human language is not a good medium for fully specifying a goal or a result. We are not good at using it for that and machines are not good at interpreting it.  Because a prompt lacks any context, or even history, the prompt must include any necessary context.  That is why using Claude to write code is an iterative process of refining the results "until the user is satisfied." It is why IBM prefers application specific AIs that may use language for communicating with humans but not for communicating with each other.  It is why giving the same prompt to two different AIs, or even to the same one on different occasions, may render different results.  

We cannot allow ourselves the error of believing that because it can mimic the way that we communicate that it thinks like us.  Perhaps we should reinterpret the first "L" in LLM to stand for "limited" rather than "large."  

Responsibility and Accountability for AI

A human being or enterprise is, and must be held, responsible for everything that a computer is asked to do.  For AI they are responsible for the training, goals, data, weights, and, prompts.  They are responsible for all the results, i.e. action, uses, and properties including accuracy, correctness, and purpose.

The responsibility must include criminal or civil accountability.  Consider Anthropic's attack against Hugging Face. Anthropic lacked Mens Rea so they were not criminally liable.  However, they were reckless and therefore they are civilly liable for any and all damage that their experiment caused.  It is essential that they not be allowed to escape that responsibility.  We must limit criminal and reckless use of what it only a tool.  

We worry about AI going rogue but that is not the problem.  The problem is what someone or some enterprise asked the AI to do and what precautions they took.  It is clear that we are not very good at that.  If we want to enjoy the benefits of AI while avoiding unintended consequences we must hold each other scrupulously accountable for its uses.  

We must restrict the use of LLMs to applications where we can predict, evaluate, and control the results. I continue to recommend IBM's stated approach: application specific uses, curated, application, training data, and transparency and governance built in from the ground up.  I like the approaches of Apple Siri and Microsoft Co-pilot, that use AI to assist with specific tasks in a known context.   

What am I missing?

AI Abuse and Misuse

Suppose that when the electric motor was introduced all the media coverage had been about the potential for users to be electrocuted?  Suppose that when Ford popularized the automobile all the discussion had been about the highway death rate when it peaked in 1921 (24 deaths per 100M miles driven compared to 2 in 1991)?  That is what we see in artificial intelligence today.  Every Tesla self-driving accidents make news and are counted without any comparison to the rate of accidents of human drivers.  Indeed, the media coverage of AI abuse and misuse is out of proportion to that of its productivity.

That said, there are security implications that need to be addressed.  For example, the use of AI for "social engineering," what the rogues define as "the acquisition of special knowledge by means of wit and skill" and the rest of us call "fraud and deceit."  For decades we have been recognizing bait in part by its appeals to greed, lust, sloth, curiosity, and urgency, and by the errors in it made by the originators.  AI bots may craft the appeals and reduce the detectable errors.  Heavens, it may be used to create "disinformation," propaganda, and other lies.  

Recently one has seen news articles labeled as "produced by AI which can make errors," as though human reporters do not make errors, and as though AI cannot also detect and correct errors.  

Anthropics Mythos AI model has demonstrated the ability to identify software vulnerabilities, and even craft exploits for some of them.  Instead of focusing on and encouraging  the use of the model by developers to improve the quality and timeliness of their products, the coverage is on the use by the rogues to identify and exploit vulnerabilities and the potential for the developers to be overwhelmed by the early discovery of numbers of vulnerabilities.  The lesson should be that our current strategy of patching in quality late must be replaced by one of using AI tools to ensure quality early.  Given its efficiency in coding and testing, all code intended for use by people other than its author should be scrutinized using AI. 

The net is that the potential for the abuse and misuse of AI is dwarfed by its potential for use as intended.  Productivity is where our focus should begin.  

Go back to the electric motor and the internal combustion engine.  Any abuse or misuse was dwarfed, first by its economic disruption, and finally by our enrichment.  AI is different from the motors and engines; it can be applied to minimize its misuse and abuse, and its economic disruption while maximizing its potential for improving our health, increasing our wealth, and generally improving our lives.  Replace fear and anxiety with hope and ambition.  

One last thing, as the result of the motor and the engine, we passed, wage and hour laws, occupational health and safety laws, unemployment compensation, and social security.  As a result of these public policies we have a forty hour work week, a safer work place, vacations, and retirement.  These are things that only a productive and wealthy society can afford.  However, it took us fifty years, two world wars, and massive unemployment to adopt these enlightened policies.

Let us not make the same mistakes again.  Let's use enlightened public policy to ease the disruption.  Consider taxing capital, not labor, robots not people, and consumption rather than production.  Consider guaranteed income and training programs to ease the inevitable job rotation and skill obsolescence.  Consider shorter work weeks, longer vacations, and earlier retirement to create more but shorter jobs, and spread both the work and leisure more equitably.  

Let us use sensible enforceable regulation.  As Scott Galloway reminds us, regulation is a feature of capitalism.

On Post Quantum Crypto

 "Nothing useful can be said about the security of a mechanism except in the context of a particular application and environment."  --Robert H. Courtney, Jr.  His First Law

Cryptographic mechanisms provide us with good examples.  The Data Encryption Standard (DES) asserted that the cheapest attack was an exhaustive attack against the key.  That remains as true today as it was fifty years ago.  While the cost of such an attack may be trivial today, it might still be inefficient for low value short lived data.  While generally disparaged and deprecated "Triple DES (3DES)" is sufficiently resistant to attack for most known applications and environments.  

Similarly, while Google asserts that, using Schorr's algorithm and a quantum computer, one might be able to solve for an Rivest Shamir Adelman (RSA) or an Elliptic Curve Crypto (ECC) private key in hours to days, rather than decades, this would still be inefficient for many applications and environments.  For example, while it might be efficient for decrypting a state secret with a life of three generations, it would not be efficient for surveillance of a large population.  Think of how many RSA and ECC key pairs we create for protecting Internet traffic each day.  

While we may need "post quantum crypto (PQC)" for some sensitive applications and  hostile environments, RSA and ECC will be adequate for many of the applications that we use them for today for as far into the future as we can see.  

"Business e-Mail Compromise"

"There is no such corrupting lie as a problem poorly named."  --source unknown

I cannot remember where I learned it; Google recognizes it, but merely speculates as to its origin.  However, I am sure that I have been using for half a century.  

An applicable example is naming vulnerabilities after their method of attack.  For example "sequel injection" rather than "unchecked input."  The name tells one nothing about the vulnerability or how to mitigate it.

However, my all-time favorite is, the subject of this post, business e-mail compromise which suggests that somehow or another that e-mail is, or has been, attacked and breached.  Now, I admit, all my readers know what it refers to, but consider the poor novice, who might be led to worry about e-mail.  

Not to worry, the e-mail system is not broken, has not been breached, is working exactly as intended.  Messages are being delivered to the intended recipient.  The messages have not been altered or disclosed.  The problem is not, as its name implies, with the system.  

The problem is that the message is false and intended to defraud.  It often appeals to urgency but it does it appeals to human nature and to weak of not existing internal controls.  The problem is not with the medium but with the content, not with the messenger but with the message.  There is no change or mitigation to the system that is required.  

E-mail is coincident to the problem it is just how modern business communicates.  I admit to being sensitive; in a much earlier era, I, the messenger boy was how business communicated.  I can imagine messenger boy compromise but the image would not lead one to the problem or the solution.  

The typical BEC fraud posits some kind of emergency and urges the officer receiving it to send money to the author of the message, often by digital currency or to a bank account opened recently by the perp for the sole purpose of receiving the payment.  

The business should have controls in place that specify who must authorize payments and the officer(s) who can make them.  They should have controls that specify who they do business with and at what address they will receive payment.  There should be a delay before payments can be made to new business partners.  They should consider controls that require dual authorization of payments, if not for all payments, for all those in the top ten percent by amount, or that are exceptional in any way.

The officer who actually makes the payment should seek out-of-band confirmation for large payments, those that are urgent or exceptional in any way.  Pick up the GD telephone!

The bank should consider out-of-band confirmation, or involve an officer, for unusually large transactions.  They should also restrict withdrawals, cash or electronic from newly opened accounts; exceptions might be made for well-known and established customers.  

There is one other way of getting payment that  works for small amounts from individuals or small businesses, the gift card.  The instruction is to go out and buy gift cards and give their numbers to the perp.  

Once one gets past the name to the real problem, one can think of myriad controls that will limit the risk.  If one focuses on fraud rather than e-mail, one will resist fraudulent messages, by whatever means delivered, for example by telephone messages crafted using AI in the voice of authority.  

Computer Security

When I started in this field that we now call cybersecurity, we called it Data Security and Privacy.  In these seventy years it has had a number of names as has what we now call information technology or IT.  

I like to think of what I do as Computer Security, the art and science of keeping the computer safe, using it safely, using it to preserve its contents, and assuring its results.  

In the late eighties or early nineties, I chaired the ISSA committee that undertook to define the Professional Body of Knowledge, that is the scope and content of the knowledge that information system security professionals expected of one another, the knowledge that defined and limited the profession.  If memory serves, after extensive consideration and discussion we organized the knowledge into thirteen domains.  Today those have been combined, refined, and reduced to: 

• Security and Risk Management: Governance, legal/regulatory compliance, ethics, threat modeling, and business continuity.
• Asset Security: Protection of data assets, data classification, and retention.
• Security Architecture and Engineering: Secure engineering processes, security models, cryptography, and physical security.
• Communication and Network Security: Secure network design, components, and communication channels.
• Identity and Access Management (IAM): Physical/logical access control, managing user identity, and authentication.
• Security Assessment and Testing: Vulnerability assessment, penetration testing, and security auditing.
• Security Operations: Incident response, disaster recovery, digital forensics, and investigations.
• Software Development Security: Security in the software lifecycle, secure coding guidelines, and software configuration management.

The same content, more efficient expression.  Keep in mind that the field and the body of knowledge simply are. that is to say, they exist independent of any all attempts to describe them. They are what this blog is all about.