Dr. Randy Burkhead, security consultant at AT&T Cybersecurity, discusses “fatalism” and the outdated approaches to cyber security that are holding organisations back and why knowing your enemy is the key to success when looking at the ever-changing threat landscape.
There is a prevailing viewpoint among security professionals that security breaches are inevitable. They have adopted the mantra, “It is not a matter of if but a matter of when.” Even to this day, this attitude has been observed and used to justify accepting easy to mitigate security risks. This ethos is nothing new and it has a name: “fatalism.”
The official definition of fatalism is, “a doctrine that events are fixed in advance so that human beings are powerless to change them.” But is that the truth? Are we powerless to change events or do we make our own choices?
When making the choice to choose compliance over security, that’s not fatalism but a mixture of choice and will. It’s a decision to be good enough to escape liability without being good enough to escape fate.
It’s a trap!
Many of the big credit card breaches of the past decade occurred while an organization was PCI compliant. Although companies become compliant, they often do so in a way that is unsustainable. Do not take away the wrong lesson. The lesson here is not if the big companies couldn’t fight the hackers, then I can’t either. The lesson is that the culmination of their decisions resulted in an environment that made the hack possible.
Choices are made every day that impact upon personal and professional destiny. Security is not an expensive goal attainable only by the super-rich. It is a goal achieved through dedication, continuous growth, knowledge, ingenuity, and heart.
There are many models available to practice cyber security. The model I recommend follows four phases: identify the environment, categorize the risks, know the enemy, and test the solutions. This model is a cycle designed to repeat itself again and again without end so that each cycle utilizes the information gathered to grow more mature with each revision identify the Environment
Phase one sounds simple. It’s the same advice given by sages, oracles, and war philosophers for thousands of years, know thyself. It is the foundation upon which all else is built. What systems are on the network? What systems are in the inventory? Where is sensitive data? What is the sensitive data? What is the normal traffic on the network? What is the normal operating usage of systems? This is a collection of facts, without judgment, about the environment. A single missing piece here may cause the entire security structure to crumble.
For example, in carrying out a penetration test for a bank several years ago it was observed that the bank had a secure system for account data. However, one of the account representatives wanted to do something nice for clients by recognizing their birthdays.
The account representative took the information from the secure database, including the account numbers, safety deposit box information, and PII of their customers and put it in a spreadsheet.
However, the spreadsheet was found with an unprivileged account sitting on the internal SharePoint platform. They did not know where their data was and had it not been found in the pentest process, they would not have known to address it.
Phase two is about putting those pieces together to figure out what it all means. What happens when assessing the systems on the network with the systems in the inventory? Rogue device detection and loss prevention. What does it mean that account data in SharePoint was discovered – which itself has its own set of environmental facts to classify? If process is missing A) how does that impact procedure? B) How do these pieces align to connect them in meaningful ways? The results of these assessments culminate in a holistic view of organizational risks.
Some frameworks for security and most organizations stop here and go no further. HIPAA, for example, does not require anything more than a knowledgeable assessment of risks. Several years ago, an assessment at a medical insurance processing company was conducted. They had individual programs for anti-virus, incident response, patch management, and inventory control that each were approved as compliant and low risk.
Yet, as soon as these facts were considered together, it was found that less than 40% of their systems were defensible. Sixty percent of their systems when compared across all programs were missing from one or more of their SecDevOpps management tools. This met the standard but not the intention of each control in order to document and use compliance as a standard for legal and insurance purposes. If a reasonable person thinks nothing more could reasonably be done to prevent, detect, or deter the breach, then that’s good enough.
Many organizations never carry forward to build out the final two critical components of this model described in the next two sections. Choosing instead to accept the things they could change and remaining ignorant of the real threats to systems and data.
Know the enemy
We can’t stop people from trying to break into networks. That truly is inevitable. Just like in war, when you can’t stop the fight from coming that does not mean you lay down and accept defeat! It is important to prepare defenses and a good defense does not simply stop at the perimeter and includes a ton of intelligence.
A good defense in the real world or for cyberspace is through layered security but without intelligence it is impossible to know what defenses are useful against which threats. It is important to design defenses to deny an enemy whatever objective they seek to obtain. In order to do that, knowing how the enemy works, how they think, and how they operate is imperative.
Take a realistic look at the world to identify actual threats. What do these threat actors want? Why do they want it? How are they likely to try and get it?
Knowing these things is not about knowing every potential attack vector that could ever be weaponized. The value comes from knowing the likely attack vectors and how threat actors operate in order to establish methods to detect, deter, and mitigate attacks.
For example let’s assume social engineering phishing scams are a threat to an organization. A link is sent to an employee with some message telling them to log in to the new portal to activate their accounts for remote work. If they do it becomes possible for an attacker to log in via those accounts to the real portal. This attack pattern is simple, but within it are several points where organizations could have detected mitigated, or even prevented this account takeover or denied the attacker their objective.
An organization could potentially identify the threat coming in, could track credential usage through packet analysis, detect abnormal logins, and could layer data security so that a single credential to the network does not also give an attacker unlimited access to sensitive data. When looking at the chain of events it’s possible to identify how to break the chain at each stage to deny the attacker any victory. That information can be utilized to build better networks designed to actually mitigate real threats rather than the cyberboogy man.
The few companies that go beyond categorizing risks typically skip the third phase and go straight to testing their solutions with assessments like penetration tests. However, what good is a penetration test that’s conducted with no actual direction or bearing on reality? When was the last time you invited a stranger to plug into your network for a week unsupervised? Never. So why test this way? What threat is the most concerning that mimics this behaviour?
Please do not misunderstand me, this type of testing is so important that it has its own section within this model. This testing phase allows a company to train their systems, people, and processes in order to learn and identify what worked and what needs to be improved through shared experience. It should not be done to the lowest level of effort.
More often than not, the first comment heard after delivering the results of a penetration test is, “we saw you, but we just didn’t stop you.” Would you let a hypothetical stranger do it? Or let an employee do it? Why let a tester do it? Detecting, deterring, and preventing an attack is the primary responsibility of security. Training only makes sense when you train the way you fight.
Every time a penetration test is conducted, organizations should watch, track, and detect the pentester’s movements through the systems.
From a personal perspective, I once shocked a client after less than three hours when I showed them how far I had made it into their networks. They could not believe it, could not detect it, and only after I had been onsite and compromised their entire network did they request we talk with my manager to verify my identity. They thought I might have been too good to be a real consultant, yet they had also made it unrealistic and too easy.
They set me up right next to their system admins so I could overhear everything, was plugged into the same subnet for man-in-the-middle attacks, and had access to the management LAN. The only way this would be a real scenario would be if I were modelling the behaviour of a malicious system admin which is only one of many potential scenarios that could have been applicable to that client.
Building upon each phase culminates in this real-world testing which gets tangible results and provides real-world data for building better programs. The results of testing and training show not only where plans fail, but where they go right. It is important to understand and identify not only the things that need to be improved but the things that worked. This knowledge makes each cycle more intelligent than the last growing and maturing with time.
When putting all of these elements together to form a continuous cycle, an IT security program takes shape. Importantly, one that understands what it has and one that knows its own strengths and weaknesses.
The IT security program can detect and prevent an enemy and it trains each cycle of its growing maturity model using real world tactics, techniques, and procedures. Military veterans may find this four-phase process familiar; it’s the same process for developing and refining intelligence planning products.
There is no doubt that hackers will try, have tried, and are trying to breach anything connected to the internet using automated and manual methods. That is something beyond our control to change.
Security professionals can impact the outcome through dedication, understanding, and hard work. Knowing the environment, understanding the inherent risks, identifying their opponents, and training to fight armed with all of this knowledge takes time and effort
For those willing to go the distance – there is no fate.