Should Paying Ransom be Illegal?

 Today Bank Info Security raised this question at:  https://tinyurl.com/on-paying-ransom

It seems clear that, at least collectively, we are highly vulnerable to breaches and extortion.  In order to take part of the profit out of such extortion we need to raise the cost of attack against our systems ten fold.  Not only will that take time but it may also require additional motivation; too many enterprises are electing to accept, rather than mitigate, the risk.  We know how to increase security; we lack sufficient motivation.  

It seems equally clear that paying ransom may be good for the enterprise and the perpetrators while putting the infrastructure, society, and national security at ever higher risk.  We need to discourage such payments.  This includes not being able to assign the risk to underwriters, as AXA has already said.  Such insurance creates a "moral hazard."  

Historically, I have opposed "punishing the victim" as a means of encouraging better security.  We managed to discourage the old "protection" rackets without resorting to that.   However, something must be done; society cannot leave the acceptance of existential risk to any of thousands of enterprises.  

Consider sanctions for paying extortion that escalate over time on a steep, but announced, schedule.  This could increase the motive to improve security while allowing the time necessary to do it.  

Finally, as with the protection rackets, there must be a law enforcement component to our response.  We cannot put all of the responsibility for protecting society from this risk on the potential victims.  Part of this response might include funding law enforcement out of fines imposed.  Another part might include so regulating digital currency as to make it easier to "follow the money."  We may decide that we cannot tolerate anonymous receipt of funds.

The Biden Executive Order

There is nothing like long lines at the gas pumps to get the attention of government.  This is an initiative that is long overdue.  There is a great deal to do.  Cyber is the infrastructure that we use to operate all the others, particularly to include energy and finance, and it is all too fragile and porous for the reliance that we have upon it.  

It is good to see that "zero trust" made the list.  The concept goes back to the mainframe and many of us have been actively promoting it for the internet for years.  It is important to use it both horizontally, that is system to system and service to service, and vertically, through the layers of the application.  

Zero Trust requires strong authentication (at least two kinds of evidence, at least one of which is resistant to replay) both user to system and process to process.  One cannot trust a process whose identity is not reliable.  If strong authentication is not the single most effective and efficient measure at our disposal, it is certainly among the top three.  It deserves its own mention.  

Zero trust also implies resistance to lateral compromise within the enterprise.  It should not be possible to compromise an entire enterprise simply by getting one user to click on a bait message in an e-mail or on a web-site.  In addition to resistance to fraudulent credential replay, we need structured networks.  I would like to see end-to-end application-layer encryption but, at least in the short run, I would settle for network segmentation and layering.  

I am glad that it addresses software quality.  However, the practice here is so shoddy and the contributors so many that simply saying we will address it through government purchasing power will not be enough.  Nor can we rely on training alone.  We need systems and development processes that make it much easier to do it right than to do it wrong.  

I would like to have seen the order address accountability and transparency for privileged users.  Edward Snowden should not have been able to run rampant through a network that one would have expected to be "secure."  It is ironic that the place that we are most likely to see shared credentials is among privileged users.  Wherever there are two or more privileged users per shift, we need privileged access policy and management systems.  

We cannot continue to allow just any amateur to connect anything they like to the public networks.  While it may require legislation, we must require that only mechanisms built by professionals to infrastructure standards (e.g., built for the ages, fails in an orderly and safe manner, resistant to easily anticipated misuse and abuse) can attach directly to the public networks.  As we need structure networks within the enterprise, we need structure within the Internet.  

We also need to have accountability for suppliers who distribute (malicious) code that they did not write.  This too may require legislation but a class action suit against SolarWinds would be a start.  

The Biden Executive Order is a start but only a start.  There is much to do.  Let us get on with it.

Policy -- What must it do?

I recently received a link to the electronic annual report of a company from which I receive service and in which I have a small investment.  I was pleased that it contained a button labeled "Cybersecurity Policy."  Needless to say, I clicked on this button.  This is what it said:

"We go to great lengths to protect our computer systems and equipment from the threat of a cyberattack. Our comprehensive network is designed to protect us from both internal and external threats. We’ve expanded our use of next-generation intrusion detection and prevention tools to further protect our customers’ personal information. And we’re regularly training our employees to stay aware of potential cyber threats."

I confess to having been more than a little disappointed.  This is more a statement of good intentions and practices than a policy.  None of my expectations of a "policy" were met.  

As both a practitioner of security and a customer of, and investor in, the enterprise, I would expect a policy, at a minimum, to: 

• require that managers protect the assets that they control.   
• express the organizations tolerance for risk or
• some measure of the level of security to be achieved, and
• require measurement and reporting of results, i.e, achievements and failures
• other

Said another way, I would expect a policy to communicate to managers and employees what general management wants them to do and how much to spend doing it.  This statement, labeled "policy," fails to do that.  

The first and fourth bullets may be difficult to execute, while the second and third are difficult to express.  Such expression should ensure:

• a consistent level of effective and efficient security across the enterprise,
• that precious resources get appropriate protection, 
• while expensive measures are reserved only for those assets that require them.

These results cannot be achieved without direction from general management.  Such direction is called "policy."  Policy is an important and useful tool for management and leadership.  

Note that management's tolerance for cybersecurity will differ by industry, application, and maturity of the business.  A "startup" may have a very high tolerance for cyber risk, in part because their business risk is high.  A mature company in a sensitive industry, such as finance, transportation, or energy, might be far less tolerant. 

Audit Trail

We do a much better job of designing our access controls than we do designing our audit trail.  We should start by identifying what an audit trail should do for us.  It should enable management to determine:

• how every record or object (e.g. program, file, record) got to look the way it looks currently,
• how every record or object looked at any given time in the past,
• and enable us to fix accountability for every significant event or change to a single process or individual.  

The result should be reliable and resistant to fraudulent modification. 

This requires that, not only must there be logs and journals of every relevant event, but that they be related in such a way as to support each other.  There should be logs or journals on both sides of any interface where control passes from one process or person to another.  For example, an application should log every request that it makes of the database manager and of the result that it gets back.  The database manager should record every request that it receives and what response it returned. 

Logs and journals should be protected from late, or potentially fraudulent, modification.  Consider reconciliation of the results of the independent processes on both sides of the interface, "write-only" processes or storage, or blockchains.  The correction of errors should be memorialized by new correcting entries, never by changing earlier entries.  

Log and journal records should include the action taken, the user or process on whose behalf it was taken, the date and time, and a reference or sequence number to make the entry unique.  In order to be able to establish how any record looked in the past, the record of the current change to a record should include reference by time, date, and sequence number of the next most recent change.  

Finally, the logs or journals should include images of the object both before and after the change.  While in some cases it may be sufficient to keep only the after image, since the after image in the record of the previous change is the same as the before image, keeping both improves integrity and further resists fraudulent change.  

Separation of Duties

One of our most efficient controls over insiders is to involve multiple parties in sensitive duties.  We assign roles and duties in such a way that: 

• individuals, simply by doing their job, act as a control upon others  
• increases the probability that errors will be detected and corrected
• such as to limit temptation or the ability to commit fraud
• such that cooperation would be required to both convert an asset and conceal that conversion. 
• so as to improve transparency and accountability 

We separate management from staff, that is, execution from setting objectives, measurement, and reporting.  

We separate the Information Technology function and application development from their managers and users.  

Within Information Technology we may separate:

• Data Entry
• Operations
• System Architecture
• System Programming
• Application Design
• Application Coding
• Program Testing
• Maintenance 
• Management
• Other

The little monks, specifically Luca Pacioli and his colleagues, that documented the idea of  double-entry bookkeeping in the late 15th Century, suggested certain minimum rules that we use today as tests.  

They suggested that the individual who creates and authorizes an account should be separate from the ones who processes transactions within the account.  For example, the person who assigns the account number for a new customer or vendor, and enters the descriptive information like name, address, Duns number, credit information etc. should be separate from the person who processes debits and credits.  Normally, managers or officers authorize new accounts while clerks, cashiers, or tellers process orders, payments, deposits and withdrawals.  

Applying these tests to program development suggests that:

• authorizing, naming, and specifying a program
• be separated from coding
• testing
• acceptance
• operation
• execution
• use
• and maintenance 

can be usefully separated.

What I tell my family about protecting their identity.

 Recently a family member asked me how to respond to a solicitation for "identity protection."  The ad appealed to fear and some of the benefits were ambiguous. 

Every time we open an account or do business, we expose ourselves to fraud.  About three percent of us will be the victims of transaction (e.g., payment card) fraud but almost one percent of us will be victims of fraud so serious as to cause serious financial loss or crippling  damage to our reputations.  Therefore, I offer the following advice in the order of its importance.  

• Use strong (e.g., multi-factor) authentication wherever it is offered.  Avoid doing business with those who do not offer it.
• Prefer purpose-built applications for financial activity.  Avoid the use of browsers.
• Prefer mobile computers to personal computers for financial activity.
• Review all account balances and activity on a timely basis (for large and active accounts, "review" equates to online and "timely" may equate to daily.)
• Sign up for "paperless" options.  (For good security these should be the default option but for reasons of "backwards compatibility," one must opt in.)
• Allow notifications.  (Again, this should be the default.)*
• Lock your identity on all three credit bureaus.  (Locking and unlocking is now easy and free but all three bureaus will take every opportunity to try and sell you "identity protection" for a relatively high annual fee.  All three have had major compromises of personal data and are not reliable.)
• Use complimentary credit monitoring from AAA, American Express, or, as offered, by your bank or credit union.
• Most card issuers now permit you to "lock" your cards, using a mobile app.  Balance this with the convenience of using the card but be sure to lock the card if it is misplaced, lost, or stolen.  
• When buying online, prefer to pay with such checkout proxies as PayPal, Apple Pay, or Click to Pay.  Avoid using debit or credit cards.  However, prefer credit cards to debit cards.  
• Do not use the option permitting the merchant to retain debit or credit card information.  Checkout as a guest; avoid signing up for accounts.  
• When using debit or credit cards for the convenience of frequent purchases from a merchant (e.g., Amazon) consider the use of a one-time or one merchant token number from Privacy.com.  
• Consider insurance against financial loss and/or expenses related to identity theft.  Such insurance is not a substitute for any of the measures above, may be redundant of protections that you already enjoy (from homeowners insurance, fiduciaries, e.g., https://www.fidelity.com/security/customer-protection-guarantee ), may be expensive, and is best purchased from insurance sources (e.g. as an optional endorsement  to one's homeowners insurance).  https://tinyurl.com/FTCreportidenttiyfraud

* While I have been writing this I have received notices of three legitimate transactions.  This assures me that I will get timely notification of fraudulent ones.  

SolarWinds

By now most should realize that SolarWinds is a compromise on an almost unimaginable scale. It is a crisis.  While there are "indicators of compromise" there are no indicators of all compromises.  While the attackers have concentrated on gathering intelligence on only a small number of target sites, all SolarWinds customers must assume that they are compromised and that there may be multiple backdoors into their systems for which there are no ICUs.  Only a small number of enterprises, perhaps none, have sufficient control over the content of their systems to be sure that they are resistant to such backdoors.

In https://us-cert.cisa.gov/ncas/alerts/aa20-352a DHS/CISA has suggested that some enterprises under some circumstances will have to "rebuild (from scratch) hosts monitored by the SolarWinds Orion monitoring software using trusted sources."  In fact, we may have to rebuild all enterprise systems.  

President Obama's chief of staff, Rahm Emanuel, famously said in 2008, “You never want a serious crisis to go to waste. I mean, it's an opportunity to do things that you think you could not do before.”  It would be tragic, if after rebuilding our systems, we should come away as vulnerable as when we started.  

We should take Rahm's "opportunity" to introduce "zero trust," indeed zero trust on steroids.  One might well start with a Software Defined Network.  One should include mutually suspicious processes, strong authentication at all levels, and "least privilege" access control.  

Rebuilding systems in month's that took decades to evolve is a daunting task.  I am reminded of what my father taught me when I was just starting out in IT almost sixty years ago.  "Son," he said, "all hard problems in information technology have one and the same answer: one application at a time."  We can do this.  We should use the crisis to overcome the inertia that has kept us from doing what we all know we should have done a while ago.  We know what to do: all we need is the leadership to do it.  

Do not worry about the cost.  Much of what we need to do, we can do with available resources.  For example, we can implement "least privilege" with available tools.  It only requires a change in intent.  In any case, there is always enough money to do that which must be done.