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.