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.  

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.  

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.   

Enterprise Network Security

Taking only the success of ransomware for evidence, one infers that too many of our enterprise networks are flat. There is a path between every pair of nodes in the enterprise.  That is to say, the ease and latency of connecting between any two selected nodes in the network is roughly the same as any two chosen at random.  This is the default that network engineers strive for.  Too often security is not even on the list of requirements.  The result is that compromise of the credentials of one end user can, and and does, bring down the entire enterprise.  

At a minimum, mission critical applications should be isolated from fundamentally vulnerable applications like e-mail and browsing.  However, isolating users, from applications, from services, from storage is even better.   Remote access should be by end-to-end application layer encryption.

Taking the isolation strategy further, create multiple layers, for example, Internet, users, applications, services, files, and storage. Nodes on one layer can access and be accessed only by those on adjacent layers.    

Finally and best, visualize a smart switch; all users, applications, and services are connected only to that switch. Think about one cable connecting that application or service directly and only to the switch (but dedicated VLANs would be more efficient.)  Any connection between a user and an application or between an application and a service can only be through this smart switch.  Users connect to the switch via TLS and strong authentication (e.g., FIDO2 for security and convenience).

The switch uses a list of rules that describes all permitted connections between an authenticated user and an application or an application and a service.  All other possible connections are denied by default, the restrictive access control policy (see Cheswick and Bellovin), least privilege, or "zero trust."  

These strategies come at the expense of some inconvenience, administrative cost, reduced function, and an increase in latency.  However, they increase the cost of attack and resist lateral spread within the enterprise network. 

Getting from a flat network to one like the ones proposed here is not trivial.  The switch must scale to the number of users, applications, services, and traffic.  The necessary and permitted connections, that is the access rules (white list), must be identified and recorded.  Mistakes may cause temporary disruption. Fortunately there are suppliers and consultants that specialize in this.  

Bits are Bits

 NIST Cannot quite get it right.  They have gone from encouraging the use of special characters to discouraging them and relying only on password length.  

The strength issue is not about what the user must enter in an ascii or other code but how much work it would take an exhaustive, or brute force attack to find it.  Both length and special characters are ways to increase the work of attack.  Each adds bits.

We first started to Insist upon upper and lower case and special character to get more bits in fixed length passwords.  While most of you are to young to  remember it, for years passwords were limited to 8 characters, or one fetch, for performance reasons.  While modern computers are so fast that performance is no longer an issue and modern database managers will accommodate passwords of any length, there may still be systems that limit the length of passwords.  Unfortunately, we forgot why we were insisting upon complexity.

Before the Internet, most end users had fewer than a handful of passwords, many only one.  Today many users have tens, even hundreds of passwords. (As I write this, I have 310.)  As the number of passwords grew so did bad practice.  Users chose passwords that were easy to remember and enter, and then reused those that met these tests.   

To resist this user behavior, many managers introduced rules to encourage strong passwords and resist weak or reused ones.  This solution has become the problem. Choosing passwords was already hard enough; choosing passwords that meet well intended but otherwise arbitrary rules is often too much.  Otherwise strong passwords, including those generated by a password manager, might not meet the rules.  Forcing periodic changes added insult to injury.  

Thus, NIST now recommends length.  While length adds to strength, the longer the password, the harder it is to enter, particularly without error.   The strength is measured in bits, not , but the use of the entire character set may help; in some special cases may still be required.  

All this is by way of saying choosing, remembering, and using strong passwords is not easy.  Choosing, remembering, and entering, more than a handful of passwords is not easy.  It has become a computer application.  Password managers are somewhere between popular and necessary.   

Courtney taught us that "nothing useful can be said about the security of a mechanism (including passwords) except in the context of a specific application and environment."  Writing guidance that covers all applications and environments has always been what we call a "hard problem."  Writing guidance that will stand up to changes over time is particularly hard.

A final word. Well chosen and managed passwords are resistant to brute force attacks.  Those are not the kind of attacks that we are seeing.  Rather, we are seeing social engineering followed by fraudulent replay attacks.  Passwords, of whatever strength, are fundamentally vulnerable to replay attacks.  Rather, we need strong authentication, that is, at least two kinds of evidence, at least one of which is resistant to replay.  Said another way, all strong authentication is multi-factor but not all multi-factor is strong.  

Prefer length to complexity, but allow the whole character set.  (Encourage complexity if length is otherwise restricted.)  Encourage your users to use a (cross platform?) password manager. Offer them strong authentication options.  Mandate strong authentication for employees.  Consider, indeed prefer, passkeys (https://whmurray.blogspot.com/search?q=passkeys).  Use biometrics for convenience in applications where replay is otherwise resisted. Prefer one-time passwords to mandatory periodic password change.  

Security Now

It is Tuesday evening.  I am listening to Security Now.  If you are not, I recommend that you do so.  

Security now features Steve Gibson, the provider of the personal pen test, Shields Up, and the author of the storage integrity progam, Spin Right.  

I find myself passing over reports of problems, vulnerabilities, attacks and breaches.  I simply wait for Steve's weekly informed analysis.  Now, I admit it, I am both old and lazy.  If I applied what remains of my intellect, I might be able to distill from the media, perhaps, as much as ninety percent of what Steve does.  After all, what I lack in intellect, I make up for in experience. Still, it turns out to be much more efficient for me to wait for Steve's articulate analysis, than to do the work myself.  

Security Now is a weekly two hour podcast on the security and privacy issues of the week.  They pride themselves on being available everywhere in every format.  While I simply rely upon my YouTube subscription, you can expect to find it in your favorite place and format.  

I hope that you find the weekly two hours to be as valuable. efficient, not to say entertaining, as I do.  

  

iPadOS 26

 The geeks have been militating to make iPadOS more like Mac OS, Android, or even like Windows.   This frightened me.  I take comfort from the fact that with iOS I am more than a click away from contaminating my system.  I take comfort from the fact that one can recommend iOS for children and people born before 1980. 

As beta releases of iPadOS 26 have become available, there have been reviews saying that the iPad is "ready for laptop duty," you  "can finally ditch your mac," and "the iPad is a full-on computer now."  

Thank God!  All the hype to the contrary not withstanding, one still "cannot change the core system or application code of iPadOS 26 directly through the user interface. Apple's operating systems, including iPadOS, are designed as a "walled garden" for security and stability. This prevents users from altering the compiled code, which is what the system and apps actually run on."  That from Apple; I could have saved myself a lot of angst if I had asked Apple in the first place.

Yes, the screen in 26 is much more like that of the Mac.  The windowing and multi-tasking are more like that of the Mac.  The file system is more capable.  There is a task bar with drop-down menus.   One can copy and paste from one app to another, indeed from one device to another.  One takes comfort in the fact that Apple first figures out how to do a feature or a function safely before adding it to the system.  

But the iPad is still an application-only computer.  It still uses purpose built apps, nearly two million of them in the store.  It is still a closed system.  Program code is still hidden.  It is a system in which one can enjoy in safety, most, but not quite all, of the benefits of the general purpose computer on which it is built.  Rest easy, Steve Jobs.

 

Attack Surface Managment

 Thanks to our colleague, Ben Carr, for the idea and the title of this post.  I wrote most of what follows in response to a post of his on LinkedIn

The attack surface of the typical enterprise includes all the users as well as all the other resources.

I think about the desktop where most of the vulnerabilities are in system code, system code that dwarfs the applications.

I think about all the applications that are on that system that are rarely if ever used.  

I think about the orphan data and servers.

I think about the excess privileges that permit entire enterprises to be compromised starting with one user who clicks on bait in an e-mail or on a web page that he visits out of curiosity.  

So, one way to manage the attack surface is to reduce it.

• Remove unused user IDs.  Reverify and reauthorize users at least annually.  
• Remove unused or rarely used applications or services.
• Install only what you really need.
• Prefer purpose-built apps to general and flexible facilities (e.g., browsers, spread-sheets, word processors).
• Hide systems, applications, services, and sensitive data behind firewalls and end-to-end application-layer encryption.
• Employee restrictive access control (i.e., least privilege, zero-trust, "white-list") at all layers
• Scan and patch only what is left (i.e., that which can be seen by potentially hostile people and  processes).
• Other.

Employee Resisitance to New Controls

One of the reasons that our security is as bad as it is, is the perceived resistance of employees to new, or even changed, controls.  Why is it that even enterprises that offer strong authentication to customers, still rely upon fraudulently reusable passwords, vulnerable to social engineering, for employee authentication?  Employees continue to rely upon passwords even though they are implicated in more than half of all breaches and even though msny strong authentication solutions are much more convenient than passwords.  Could it be, at least in part, that management wants to avoid the inevitable employee whining that accompanies any and every change in controls?

Its true!  Many, not to say most, employees do whine and complain over any change in controls.  Even good managers are deterred from such changes by such resistance.  The good news is that most of the resistance only lasts a day or two.  Even those who complained the earliest and loudest get over it in a day or two.  They do not continue to resist what they quickly come to see as inevitable.  

Oh its true, a few continue to complain.  Let's face it, they were not happy yesterday, they will not be happy tomorrow, their happiness is not within management's control. They are grievance collectors, Failing to do the right thing in an attempt to quiet their complaints is futile.  Get over it.  Do the right thing.  

Increase in Identity Fraud

A recent report from Transunion, https://tinyurl.com/TransunionFraudReport suggests a disturbing increase in credit fraud using both synthetic and stolen identities.  Here are my thoughts.

There is no more important rule in banking than "know your customer."  Unfortunately, this works against the pressure for new accounts.  Every banker must learn to balance these.  

My credentials folder begins with my birth certificate and my Social Security Card, but also contains my high school diploma, my military discharge, my college degree, my passport, RealID drivers license, my Global Entry Card, my health insurance card and Medicare Card, my certificate of retirement from IBM, my Naval Postgraduate School Identity card, my professional certification, and two Club Identity cards.  There is a spread sheet listing all the credentials with their issue date, and the name and address of the issuing authority.

Any and all of these documents are available to support any application that I might make.  While any of them might be forged, the chances that the collection is forged is vanishingly small.  While few people have all these documents most have some of them.  

Most of the issuing authorities can be queried to test the accuracy and authenticity of the document.  While some of the documents were issued in the analog age, most of the issuers now use digital systems and records.  They could all offer an online verification capability at low cost or even at a profit like the credit bureaus.  While it is unlikely that all issuing authorities will ever offer such a service, the numbers will increase as costs go down and value increases.  

These documents speak only to my identity and existence, not to my character, capacity, and collateral.  For those one must look to the plethora of data about me held by the commercial, financial, and other institutions with which I do business and can use as references.  Many, not to say most, of these are customers of and contributors to the credit bureaus that record and sell my credit history.

In short, there is a plethora of evidence that lenders can rely upon to know their customers.  There will always be some bad lending decisions, some the result of fraud.  Tolerating a small amount will always be more efficient than eliminating it all, but striking the balance is what bankers are paid to do.

    

 

Insider Risk (not Threat)

Over the last decade the media has been full of "threat," almost to the exclusion of "risk."  It should not surprise anyone that insider risk has been written of as "insider threat."  It is true there is a small threat from insiders but it has a very low rate of occurrence.  The real concern for insiders arises from consequences, not threat.  The high rate threat comes from outside, not inside.  Outsiders damage the brand: insiders bring down the business.  The threat is from the outside, risk from the inside.

Most of our employees really do want to do their jobs.  In the rare cases where they fail it is more likely to be accidental rather than malicious.  "The dummies have it, hands down, now and forever."  No matter how damaging, mistakes tend be overlooked, accepted as normal and unavoidable, and forgiven.  Even malice is more likely because of a management failure to train,  supervise, and reward, rather than a failure of motive on the part of the employees.  

Conrad Hilton, the founder of Hilton Hotels, used to display in his guest rooms what he called the  Eleventh Commandment, "Thou shalt not tempt."  My favorite ethical test is, "Nice people do not do that."  I learned my second favorite ethical test at Nortel in Canada.  When i asked my client to describe Nortel's ethical culture he said, "Behave as though your mother were watching."  Good managers watch like "Mother."  

Malicious insiders may be needy, greedy, or disgruntled.  The needy or greedy resort to fraud and embezzlement, while the disgruntled lean toward destruction.  Even the fraud may be rooted in part by a failure ot management to properly address error.  The employee makes a mistake; no one notices.  He repeats it and again no one notices.  He begins to think that a deliberate act, one in the direction of his benefit, may similarly go unnoticed.  

Watch for good numbers.  If the numbers are too good to be true, they are not true.  

The disgruntled employee is most likely upset because he believes that his worth and his contribution to the enterprise have not been properly recognized and rewarded.  However, that feeling did not occur suddenly,  He did not go home happy on Tuesday night and come in and take the place apart on Wednesday morning,  The disaffection grew slowly over time.  It likely did not go unnoticed.  His managers likely knew that he was not happy but had delayed taking action until it was too late.   Perhaps please, thank you, and attaboys are the most efficient controls.  While not a substitute for proper compensation, they do not cost much.  

Speaking of proper compensation, the higher up the management chain, the more important it becomes.  It must take into account the economic contribution of the scope managed.  It must also take into account the economic discretion that the officer exercises.  One of the reasons that we see corruption in government is that officials are not compensated in proportion to the power and influence that they exercise.  While such compensation may be hard to justify politically, it does work to limit corruption.

While management tends to worry about IT, and IT failures get the media attention, most fraud takes place in business applications.  Workers steal where they work, e.g., accounts payable and receivable, payroll, goods, inventory, credit.  IT people are more likely to convert capacity than to manipulate business applications.  

While management tends to focus on those engaged in low level routine, think clerks and tellers, the real damage comes from officers and professionals.  Tellers steal small and are caught early.  Officers steal big and may not be caught for years.  However, one must take into account the power and fragility of IT, when managing employee satisfaction and morale.  

Few embezzlers started out to steal big.  They started small but it was not detected: temptation. It became habitual and grew in magnitude over time.  Early detection and correction is essential.  

One last thought before we go.  The most effective control over insider risk is management supervision.  Everyone deserves to be supervised by someone who knows enough to understand and appreciate what they do.  On the other hand, automated controls and procedures are often more efficient than expensive supervision.  While we use them because they are efficient, they are effective only in the presence of good management.  They are hardly ever effective in controlling managers and executives.  

In summary, think risk not threat, error before malice, business before  IT, managers and executives before tellers and clerks, supervision before automation.  

 

Where to Spend your Next Security Dollar

Strong Authentication

At least two kinds of evidence, at least one of which is resistant to replay.  Mandatory for all but the most trivial systems and applications.

Privileged Access Management

Limited number of uniquely identified, authenticated, accountable, and supervised privileged users (no sharing of IDs or passwords).  Mandatory for all large enterprises, recommended wherever there must be more than one privileged user.

Document Management System

a system, process, or database to capture, track and store electronic documents such as PDFs, word processing objects, and digital images of paper-based content, providing accountability for all content, changes, and access or use.  Mandatory for intellectual assets (IP), personally identifiable information (PII), client, customer, and employee relations, or financial records; recommended for all confidential or sensitive information.  

Structured Network

Layering of your network such that user to application, application to application, server to server, and server to file and storage system communications are isolated from one another such that any layer to layer communications require additional authentication and privileges or capabilities.  This can be implemented using wiring and "firewalls," or cryptography (e.g., VPNs, Software Defined Networks (SDNs).  Recommended for all large enterprises.  

Travel Guidance

 Canada, France, Germany, Denmark, and Ireland are issuing new guidance to their citizens traveling to the United States.

https://www.travelandtourworld.com/news/article/france-denmark-germany-and-ireland-join-canada-in-urging-travelers-to-use-burner-phones-at-us-borders-amid-digital-surveillance-and-detention-fears-new-update-you-need-to-know/

I have always cautioned business executives to use "disposable" devices when traveling abroad or crossing into the US.  No data, just clients for accessing business e-mail, data, and applications in the enterprise or cloud. This is because customs agents have extraordinary power to search and seize without cause or warrant. There have been abuses but mostly by over-zealous agents; no discernible pattern. I do not think that there is a policy but DHS has consistently refused to disclose whether or not they have given instructions to the agents.

 

All that said, if surveillance, seizures, and detentions have increased under the new administration, I have not seen any reports. This new guidance from these countries may result from nothing more than uncertainty, or it may even be political. Nonetheless, if there is a problem, I plan it to alert and advise you.  Watch this space.  

 

I am leaving the country in May and returning in June. All of my data is already in the cloud, mostly for device independence.  Just before returning,  I plan to erase the clients from my phone and tablet.  It will be simple enough to reinstall them from the app store after I clear customs.

Signal Gate

 I find that if one Googles SECOPS the "meaning" includes information technology.  I confess that in my course of information security management at the Naval Postgraduate School to O-3s and O-4s I did teach SECOPS.  However, the concept dates from when the only information technologies of interest were paper, telegraphy, telephone, and radio, long before we had invented the term "information technology."

In the first armed conflict of my life, known colloquially as WWII, we taught "Loose lips sink ships."  One does not repeat many things that one learns in the course of one's job.  

We taught not media but content.  What information did we want to keep secret; media was hardly even thought of.  Even  as I taught it, it was about what those who were to carry out the "operation" had to know about it and the potential for them to leak it.  At the O-4 level, it hardly occurred to us that the Secretary of Defense and his peers and colleagues were part of the operation and a potential source of a leak.

The association with IT deals with the porous nature of IT and the potential for adversaries to learn the content from our leaky media.  

Let us start from the non-IT meaning of SECOPS, any "information about a military operation is born classified as SECRET, regardless of whether or not it is ever recorded or shared.  At the "operational" level, O-3 and 0-4, your life may depend upon the continued secrecy of what you must know to carry out your mission.  Therefore, such information is born SECRET; one must share that information, by whatever means, only on a "need to know" basis.  Said another way, if the sharing is not essential to the success of the mission, then do not share.

Add modern recording and sharing technology to the equation; just think "chat" in its many forms.  Many implementations of chat, including iMessage, Signal, WhatsApp, and, more recently, RCS.  provide device to device encryption.  In the network, the traffic is encrypted.  However, it is in "clear text" on every device in the group.  The more participants, the greater the probability that the content will leak, or even that one or more of the devices in the group have been compromised.  

Most implementations of multi-party chat, like Signal, will enable any member of the group to see the identifier of the sender of any message.  However, the larger the group the less likely that every member will know, or even recognize, every other member (Oh!  That Jeffrey Archer).  Moreover because of the limits of the screen they may see the identities of all the members of the group only upon request rather than by default.  We call silent members lurkers. 

Said another way, multi-party chat is not considered to be sufficiently secure for SECRET data.

In the Second World War, the British were reluctant to share intelligence with us because they feared that we might leak.  Our Wave Bombe operators, who never told anyone what they had done during the war, were shocked, when after forty years the Brits began to talk about ULTRA.  9/11 happened in part because the CIA and the FBI did not trust the others security.  The consequences of Signal Gate will include a loss of trust and a reluctance to share vital intelligence.  

Most of those with any knowledge about a military mission will have been indoctrinated in operational security, both in training and experience.  Here we had a case of novices, those who did not have experience, who had not grown up in the tradition of SECOPS.

Recent Massive Data Breaches

 Given the recent breach of a data broker, the credit bureaus, and the Dark Web, everyone's personal data is available for a rapidly declining price.   We are all vulnerable but the bad guys cannot get to us all.  That said, the prudent will freeze their credit reports, use strong authentication, and maintain a vigilant posture.

I am not a big fan of data monitoring services; they are targets and increase one's personal attack surface.  However, we really need to monitor the social security numbers of children.  They are often used in synthetic identity applications.

Business should rely on full name and address or name and place and date of birth, not SSNs, as identifiers; no one else with my name lives where I live or was born at the same place and time.  SSNs were necessary when storage (in 80 column cards) was dear.  They are not even necessary in modern databases and cheap storage.  The last four or five digits of the SSN may be used for verification and as tie breakers in some applications.

"Securable" by Design

"Secure by Design" suggests that one can design an airplane that cannot run out of fuel or collide with terrain or another aircraft.  Rather, the goals should be "Securable by Design" and "Safe Out of the Box."  Such a design should begin with a  statement of ranked requirements in which security requirements are included with all others.  For example, things that the product must not do should be ranked  with things that it must do.  Failure modes must be explicitly identified along with the indicators of failure and the indicated corrective action.  Engineers have been doing this with hardware for millennia.

Complete requirements describe:

• The environment in which the system must operate (including natural and artificial hazards and threats)

• The market or market conditions

• The results that the system must produce (e.g., move passengers and freight, computing application, user programming)

• Performance (e.g., passenger load, range, speed, users, standard operations per unit time)

• How it must function

• Required/forbidden controls (e.g., over-ride of automated controls)

• The granularity of the controls (maximum rate of climb, number of named users or resources; controls must be sufficiently granular that one can implement the rule of least privilege.)

• Things that it must not do (e.g., stall near cruise speed, leak information between users or compartments)

• Specific threats that it must resist (e.g., lightning, easily anticipated abuse and misuse, hostile use of controls) 

• Cost for overcoming resistance (e.g., cost of attack)

• Impermissible failure modes and their alternatives (e.g., halt before leaking)

• Reliability

• The availability of the system (mean-time before failure, mean-time to recovery)

• Efficiency

• Maintainability (“Function may not trump maintainability and reliability.”)

• Compatibility

• How it is to be demonstrated (e.g., testing, third-party evaluation)

• Other

Complete Specification

By habit and culture, engineers use a complete specification for a system. By contrast, IT developers often work from a specification that is less than complete. A complete specification includes an expression or description:

• Of how the system is to achieve the requirements

• What functions it will perform

• What it will look like

• What materials it will be built from

• What controls and interfaces it will present

• How it will fail (failure modes)

• Indications or evidence of failure

• A model or prototype

• Users or operators manual

• Assembly processes

• Testing or demonstration procedures

• Other

Prefer eSIMs

The SIM (Subscriber Identity Module) is a finger nail sized integrated circuit (IC) that fits into a slot on your wireless phone.  It stores a number called the International Mobile Subscriber Identity (IMSI) and its related key.  

The IMSI is what associates your mobile phone with your telephone number and your mobile service provider.  It is "provisioned" by your service provider when you open your account and place it in your phone.  If you get a new phone all you need to do is move the SIM to the new phone in order for your number to ring on the new phone. Your number travels with the SIM.

Your phone also has a unique identifier, the International Mobile Equipment Identity, or IMEI.  When you make a call, the system sees both the SIM and the IMEI.

Your service provider also has an account number for you that they use to record all the information about your plan, your charges, payments, and balance or credits due.  This number is unique and binds you and your carrier.  It remains the same across phones, phone numbers, and SIMs.  

Many of us use our phones as evidence of our identity in systems of strong authentication (at least two kinds of evidence, at least one of which is resistant to replay).  This takes two forms.  We may have a "soft token" (e.g., Google Authenticator, Microsoft OKTA, Symantec VIP Access) on our phone. This is an app that generates a one time password every minute.  The app is synchronized with a server in the Internet.  Another app, for example for your bank account or other business application, may prompt for the OTP at logon time.  It will submit the number you supply to the server to ensure that you have the soft token.  Possession of the phone, "something you have" and can use, as one form of evidence in a system of strong authentication.

Alternatively, you may register your phone number with an application provider.  At logon time, the provider may send a OTP message (SMS) to your phone which you can copy and paste into a prompt at logon time.  Only someone receiving the text, that is can receive text at that phone number, can successfully logon to the application.  This is marginally more convenient than the soft token; it is also marginally less secure.  It depends upon the application provider having the right phone number associated with your account, and your wireless service provider having your phone number associated with your phone.  

Herein lies the limitation of this measure.  If an attacker can dupe your wireless service provider into re-assigning your number to his device, then he can receive the OTP message.  Because this attack usually involves the wireless service provider also giving the attacker a new SIM, this attack is known as "SIM swapping."  A similar attack involves duping the application provider into  changing the wireless phone number associated with your account to that of the attacker.  Both of these attacks require duping support personnel.  (See also "port-out" attacks.)

Note that support personnel are trained and motivated to be supportive.  If they think that they are talking to you, they will do whatever they are asked.  Of course, they are also trained and motivated to be sure its you but there are lots of them and their training may be spotty.

This is where the eSIM comes in.  Instead of storing the IMSI on an IC, in late model phones it can be stored in a High Security Module (HSM) on the phone.  Instead of being provisioned by support personnel at your wireless provider, it is provisioned by you either by running an app on your phone or scanning a QR code.  

The app comes from a network service provider (e.g., AT&T, Verizon, T-Mobile) or a contractor (e.g., Consumer Cellular, AARP, Mint Mobile, Nomad) with those that do.  It is to be hoped that you are a little more concerned with your identity than any of these service providers.  These contractor service providers, that do not operate their own networks, may compete on the basis of price, coverage, data plan, or a combination of these.  While some may provide a SIM card for old phones, for late model phones they use eSIMs.

In any event, if your phone suddenly stops working, you may be the victim of a SIM swap.  Contact your service provider immediately.  Do not hesitate.