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.  (Prefer Passkeys for a good balance of security and convenience.)
• 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 usually opt in.)
• Allow notifications.  (Again, this should be the default.)*
• Freeze 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.  
• When paying at the point of sale, prefer "contactless."  This resists the leakage of the Primary Account Number on the magnetic stripe.  Most banks now offer such cards and both Apple and Google Pay offer.
• 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.  

Slides from my NYMJCSC Keynote.

 https://tinyurl.com/MurrayNYMJCSC

This tiny url will be decoded for you before you open the synonymous link.  

Prefer Simplicity

"In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away..."

        -- Antoine de Saint Exupery (Aviator, Mechanic, Poet,

      Exemplar), "Wind, Sand and Stars"

“Simplicate and Add Lightness”

        -- Design philosophy of Ed Heinemann, Douglas Aircraft

      (Also attributed to Igor Sikorsky)

“Make everything as simple as possible, but not simpler.”

        -- Albert Einstein

“One should not increase, beyond what is necessary, the number of entities required to explain anything.”

        -- William of Occam

Engineers, indeed even philosophers and poets, have a preference for simple designs. They eschew (gratuitous or unnecessary) complexity. One need not point out that IT designers and those who secure those systems have no such preference. Engineers try to do nothing in preference to the wrong thing. They recognize that the greater the complexity of a mechanism the greater the potential for failure. They recognize that the greater the complexity of a mechanism the more difficult it is to know yourself that it is performing correctly or to demonstrate to others that it is doing so.

Simple designs are easier to implement, demonstrate, and maintain. Engineers promote the KISS principle. They call simple designs “elegant.” They recognize that complexity causes errors and masks malice. Engineers manage “parts count” because they know that quality goes up as parts count goes down.

Awareness Training, the Message

It was a long time ago.  I was doing data security market support for IBM.  I thought of my job as helping IBM customers keep their computers safe, use them safely, and use them to protect their contents (from accidental or intentional modification, destruction, or disclosure).  There were a manager and three professionals doing this work.

There was another security group in IBM, much larger, responsible for how IBM's intellectual and other property was protected.  They were piloting their first "security awareness" program.  As a courtesy, they invited me to sit in on one of the pilot sessions.  Their intent was, that if the pilot program was successful, they would make it mandatory for all employees.  

The program was motivated in part by a major breach of intellectual property.  A competitor had called to tell us that someone had just offered them the design of what was to become one of IBM's most profitable products, a new disk drive, code named WINCHESTER, which was to launch an entire industry.  The design was offered to the competitor  for $50,000 and that price included monthly updates for a year.  

Not only was IBM's general management upset but the competitor was equally so.  His position was that he could absorb full development cost and still compete.  What he could not do was compete with a mutual competitor who got the design for a pittance.  That if IBM could not keep its own secrets, the next time he was offered such a deal, he would take it.

While the perpetrators were caught and the design documents were recovered, the lesson was not lost on IBM management.  They were going to ensure that the problem was fixed.  The pilot program was to be part of the fix.  

I sat through the program not once, but twice.  When I was asked if I had any reaction, I said that the course was a great lesson in how to commit fraud and intellectual property theft, that it was a good description of the problem but was likely to make it worse rather than better.  

When asked what I would recommend, I suggested that the program be shortened perhaps to as little as fifteen minutes and that the message be shortened to what we expected the managers, professionals, and other employees to do.  

IBM actually had a robust system for classifying and handling data.  It defined how data was to be classified, labeled, and handled.  Most of the documents created were public.  Indeed, at the time IBM was one of the largest publishers in the world, second perhaps only to the US Government Printing Office.  Other documents were classified and labeled as "For Employee Use Only," along with two levels of "confidential."  Confidential meant that use of a document was to be on a "need to know only" basis.  Each level was defined by the controls that were intended for that level.  The highest level, "Registered Confidential," was intended for a only a very small number of documents, those whose disclosure might affect profitability, and where the controls included limiting and numbering every copy, keeping them under lock and key, and logging every use.  

What IBM really needed was for every employee to classify and label documents properly, know the procedures for every class that they were likely to handle, and follow the procedures.  That meant that most employees needed to be trained only on public and employee use only, a smaller number on confidential and "need to know," and only a tiny number on how to recognize, classify, and handle the "crown jewels."  

It was much easier to teach this.  Not only did this focus increase the effectiveness of the program but it greatly reduced its cost.  Keep in mind that this was in an era when most information was still stored on cheap paper rather than on expensive computer storage media.  The more sensitive the data, the less likely it was to be in a computer.  It was very different from today where we use little expensive paper, and store the most sensitive data in cheap computer storage.

The lessons for today are very different but the emphasis of awareness training should be the same.  Focus on behavior, what we need for people to do.  Focus on roles and applications.  Leave descriptions of the environment, the threat sources and rates, the attacks, the vulnerabilities, the problem, to the specialists.  Awareness training should be about the solution, not the problem.