Security Blog – JJD Software Security Topics

5 Reasons WIRED.COM Got it Wrong – You Won’t Believe #3!

In the October 23, 2016, WIRED.COM article “Inside the Cyberattack That Shocked the US Government”, author Brendan I. Koerner presents an excellent chronology of the cyber attack at the U.S. Office of Personnel Management (OPM). This overview, however, includes a reference to a fundamentally flawed but universally understood cyber security tenet; one that is THE reason we have been (and will continue to be) afflicted by massive data breaches:

“THERE IS A COMMON misperception that the surest way to frustrate hackers is to encrypt data… The first item groups like these usually swipe is the master list of credentials… the ideal is one that belongs to a domain administrator who can decrypt data at will.”

At will no longer: This dogma is about to be turned upside down.

A revolutionary new approach to cybersecurity removes the ability for the domain admin account (along with all other accounts) to view protected assets, all while continuing to allow people and systems to perform their necessary work functions. This is accomplished by combining already proven cryptographic approaches with a unique system of hardware, key and privilege management.

With the TSM Lockbox, we’re debunking several widely held misconceptions:

The Queen Bee paradigm – Every security system/network contains ‘the’ account that ultimately has controls to all other locations and accounts. Using our methodology, we have a hive where there are certain places the queen bee cannot go or see.
The universal exception – The highest level account can turn off, reset, change, or cancel all known cyber security protections; for example passwords, multi-factor challenges, key stores, etc… Using our approach, possessing these privileges will still not allow the domain admin (or any other account) to see protected information.
Not in my backyard – In the cloud, the highest level account is held by third parties. With our software, those third parties still cannot see protected data.
Doing the same thing over and over again and expecting different results = #Insanity – Current cyber protections ignore the most persistent threat – the omnipotent domain admin account. Launching our innovative solution, this most paramount vulnerability is addressed directly.
Humans vs. the machines – Larry Ellison of Oracle believes pitting humans against the Artificial Intelligence (AI) soon to be brought to bear by hackers will only make vulnerabilities worse. With our approach, no account (machine or otherwise) can see secured information.

The vast majority of the successful cyber miscreants of the world (see Equifax, OPM, Anthem, etc…) have very little interest or motive to tackle the plethora of formidable cyber fortresses wrought by the billions of dollars spent annually to keep them out; they don’t need to.

Albert Einstein once wrote, “The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” Big Al nailed it.

So long as the process of our current thinking is predicated on the universally accepted doctrine that the domain administrators must and will have access to the keys to the kingdom, hackers need only focus on getting these credentials–and they can–and they will.

The real question is: What do you want them to be able to see when they get there?

Got questions? I have answers. Email justin@jjdsoftware.com or Twitter @donohoe_justin.

Is Encryption Really Not the Answer?

I am starting to get the impression the phrase “Encryption is not the answer” is becoming the chic catch phrase ‘du jour’ among security professionals. I was attending a high profile cyber-security conference recently and heard this statement uttered on more than one occasion to very large audiences (although I must add that one of these experts did add a meek “by itself” one time).

This trend is leading me towards my own new catch phrase of the day: “When did this happen?”

I think this provocative catch phrase has gained traction in light of the latest round of large-scale data breaches. In December 2013 Target reported a major data breach even though the data was encrypted. Most recently, it has been reported that in the Anthem data breach the data was housed unencrypted, but the attack was sophisticated enough that experts have published blog entries stating that Anthem was right not to encrypt their data because it would not have stopped the breach.

Here I would like to point out one of the tremendous advantages of proper encryption – as long as the key is not compromised, encrypted data stays protected everywhere it goes. This includes (but is not limited to) stolen hard drives, stolen backup tapes, breached database backups, stolen or intercepted data transmissions, stolen or compromised files with sensitive information, stolen laptops or other personal devices, etc… It can be reasonably argued that data encryption is largely the reason why these types of data breaches are no longer in the news and fortress type breaches are now more the norm. It makes me wonder if, had the attackers known the data at Anthem was not encrypted, they would have simply opted to ship one of the database backup files to an external data store. Reportedly, the breach was detected when one of the system admins noticed a rogue query that he did not initiate being run using his identifier code. By taking a backup file instead it is possible that the attackers never would have been detected.

To use a potentially misguided analogy, I feel like some of these experts are saying people are right not to wear seat-belts because recent automobile fatalities have been attributed to rollover accidents and passengers would have died anyway. Perhaps a more appropriate assessment would be to continue wearing seat-belts but, in addition, take measures to reduce the risk of rollover accidents. If we apply the transitive property (notice the addition of a misguided math analogy), I feel the more responsible expert opinion may perhaps be: “In addition to encrypting sensitive data, care and resources need to be dedicated to protecting key user credentials, securing and monitoring networks, and training personnel on good cyber hygiene.”

If the pundits are trying to say that encryption alone without utilizing other measures is not enough, I can understand that position because it helps managers to realize that simply encrypting data does not mean that all threats are eliminated. By leaving out the ‘alone’ or ‘by itself’ caveat, however, the mistaken impression can be that data no longer needs to be encrypted. And that gets us into ‘out of the frying pan and into the fire’ type stuff – three analogies and I am out.

How Best do You Balance Adequate Data Security with Productivity?

– By Justin Donohoe, May 5 2015

It was a seasonally cold winter morning, and I had been afforded a rare window to beat the morning rush and get into the office early. The only sounds in those early hours were the periodic clicking from the automated lighting systems and the persistent drone of a printer churning out copious pages of an overnight report. Due to the early hour, the smell of freshly percolating coffee had not yet begun to waft through the office.

Enjoying the opportunity to focus on a backlog of project needs, I eagerly dove in to get a head start on the day. But my enclave of focus would soon be interrupted:

“Do you know what is on these pages!” demanded a women standing in front of me with the stack of papers that had been accumulating on top of the printer.

Startled and bewildered, I took a brief moment to regard this very animated woman. She was close to retirement age and had a smart, almost prim appearance that stood out somewhat from the casual attire worn by the contract staff that comprised the majority of the work force in this section of the building. I recognized this person as full-time but could not put together enough information to determine the relationship she may have with my team managers. I had no idea what was on these reports or what group she represented, but I could tell immediately this was not going to be a pleasant encounter:

“Personal information for every single employee along with their salaries – that’s what!”

I had enough of a background with encrypting sensitive information to understand the import of this development. I could also sense that she had grown impatient with my lack of a response: “Did you hear me! Every single one! Names… Social Security numbers… addresses!”

I began to surmise that this woman was aware that I was the only consultant in at the time:

“DID YOU PRINT THIS?” she demanded sternly.

“No, I did not.” I responded firmly but calmly.

“WELL WHO DID?” she insisted.

Not unlike so many other security sanctuaries built to keep the miscreants of the cyber world out and keep sensitive information safe from prying eyes, this organization possessed what could be described as a formidable security fortress. To my knowledge, it has never been breached or hacked. Armed with vast technical resources and ample technology funding, these cyber vaults are very hard to breach – from the outside.

The truth is, however, that many information breaches do not come from the outside – at least not entirely. Within the sanctuary of trust, staff must be able to process and work with the protected information that has been collected. In other words, even within the most secure vaults the data needs to be ‘unlocked’ at some point so that people and/or automated programs can make assessments and determinations on the information. Nefarious internal resources or simply savvy opportunists may exploit this vulnerability as a way to get at sensitive information from the inside if organizations are not careful.

I never found out who printed the report or what the ultimate outcome was, but I have never forgotten this encounter. Whether this was an innocuous test run of a report or surreptitious attempt to steal thousands of valid identities for profit, had it not been for this woman, any one of the hundreds of people in that office could have easily taken this printout and created a significant and undetected security breach.

While her diligence is both admirable and commendable, the main lesson I took away from this event is that “she” may not always be there. To this day, I make it a point to design and architect technical solutions and processes so that organizations can meet their business needs while making sure sensitive data remains secure, including inside the sanctuary of trust.

In addition to designing secure software, however, there is an equally important facet to making the applications within an organization more secure. Project leads need to work with key system users to determine precisely which information is required to complete the tasks at hand. Note that the key here is the “Less-is-More” rule. Here are some basic questions to start with:

Does the system need to pull and/or display any sensitive personal information?
If so, can any of it be masked or obfuscated?
If not, how frequently does the information need to be pulled?
Is any sensitive information needed for reports?
If so, which actors need to see these reports?
How frequently will these reports be run?

In the early days of software application development, systems were designed to be at-the-ready to pull helpful information to be able to offer assistance to users in order to increase productivity. This paradigm has changed. Users today need to be part of the solution and assist designers in working to only pull the least amount of personal information required to get the job done. For example:

“I need to see any records related to S. Samson”

can be reworked in the front-end to…

“Return to me an integer representing the number of matches for S. Samson”

…then perhaps allow the user to inquire more deeply if necessary.

The goal needs to be ‘let’s think about what if this was my information’ and how can we design systems to allow for the least required access to sensitive personal information. This will help arm today’s system architects with the ability to further lock information away from cyber intruders as well is internal threats.