Security-oriented news often stays within the security community, that is until it hits home, or often millions of homes. We’ve most recently heard about breaches at National Public Data and Ticketmaster, but there are names from the past that might provoke a twitch or send a chill in those who have been following the industry for some time. Names like Sony, TJX, etc. While household names from a brand perspective, they also are associated with now infamous events in the security world. While these names represent the “crossover” events between the general public and security professionals, they, or more specifically the missteps that felled them, continue to haunt companies today and make them additions to the history books. Let’s examine, through the lens of some historic breaches, the five most common mistakes that still serve as a catalyst to compromise, and best practices to keep yourself out of the classroom curriculum.
Clean up in Segment 7…
Our first tectonic event was at Target, where attackers jumped from the company’s connected HVAC (Heating, Ventilation and Air Conditioning) systems all the way to store Point-of-Sale systems and ended up shoplifting more than 40M credit cards.
As Shrek said, “it’s all about layers”. Too many organizations suffer from a very flat architecture, with the boundaries between external resources, users and servers largely open and providing little-to-no resistance to an attacker. This flat structure “approach” extends to other zones, such as 3rd party networks, subsidiaries and operational technologies (such as HVAC, manufacturing or industrial control systems). There are two levels to defining and then defending your layers.
Planning is the first and most basic of architectural measures. Clearly delineating boundaries between zones, what connections and activities are allowed or denied. This is done with edge devices such as firewalls and intrusion detection systems, but as we all know, the best laid plans…
Purpose-built technology is the next step. Tooling is the more advanced level of architectural hardening. There are a host of technologies from companies like Illumio, that enable more granular, and even dynamic, on-the-fly segmentation.
When Snowflakes aren’t unique
Just last year, more than 150 companies fell victim to compromise, with the common denominator being they all hosted cloud assets with cloud behemoth Snowflake. However, it became quickly clear that the commonality at the core was not the cloud vendor, but the common mistake made by all – poor credential hygiene in both user and corporate systems.
Credential abuse is the starting point for so many breaches, so credential protection needs to be the most important of security table stakes. Protection of these powerful and pervasive assets is a responsibility and a requirement across multiple constituencies and processes. Let’s discuss the four levels of ensuring credential hygiene.
The first is focused on credentials and the users who hold them. Companies need to require and enforce strong password hygiene on all users. This should not just be limited to employees, but anyone that interacts with business systems, including customers. Since not all users understand the issues and mechanics involved, offering strong and clear guidance on the dangers of password reuse or insecure creation, and how to ensure secure conventions is a critical need.
The second level is enabling the processes and tools to ensure effective secrets management. No matter how strong, the best of passwords can be easily felled by being in discoverable places like Confluence or Sharepoint pages, Git repos or Jira boards, or Sticky Notes. To combat this, organizations should provide access to, and require the use of password managers to ensure credentials can be both strong, and easy to use.
The third level is “secure by design.” Organizations need to help developers by providing and enforcing secure coding practices to prevent the exposure of credentials or tokens in code.
Finally, and we’ll dive deeper into “safety nets” a little later, understanding that no password or process is infallible, so requiring the use of additional factors in authentication should no longer be considered a “best practice” but an absolute basic control.
What’s in your permissions?
All too often compromise comes in simple human error. For Capital One, it was a mistake and misconfiguration that allowed an attacker to steal 100 million consumer credit applications.
This breach is a poster child for the problem of privileges. They are called access “privileges” for a reason. Not everyone should have the “right” to access everything. Many organizations are overly permissive to account for unforeseen business friction. Wider permissions allow processes to flow more freely and and account for future growth. Unfortunately, that is literally leaving the door wide open for abuse and compromise.
Think of it like a house, if you leave every door and window open, from the basement bulkhead to the skylights, all manner of pest and perpetrator will find their way in.
Starting at the bottom, Active Directory is the identity foundation. Every unnecessary permission – users, devices and applications – puts a crack in that foundation. Many organizations leave access too broad at local or even domain levels, nesting groups based on locations or departments, giving all users in the associated groups permissions only a few need, or should have.
On the first floor, users are your current residents or trusted neighbors. First off, the locks should be changed from the previous owners and old users should be expunged. Also, not everyone needs access to your trophy room or your gun safe. Starting with their own systems, every user should not be an admin on their own system – yet in many companies they are. Employees also should have access to only the systems they need, and critical access should only be provisioned for a select few.
We’ll end upstairs. The upper floor windows and skylights are your cloud instances. Organizations need to find and lock misconfigured and wide open cloud resources. Additionally, enforceable processes should be in place for how new resources are approved, configured and deployed.
No Telltale Heart
If we’re building a data breach Hall of Shame, Heartland Payment Systems is a candidate in which attackers feasted for more than six, undetected months on more than 100 million credit cards. The massive payment processor was indicative of a wave of what we’ll call compliance reliance. Industry standards like PCI laid out security requirements for the protection of customer data. Unfortunately, many companies checked the boxes on these requirements but ignored the fact that they were simply a baseline. An industry standard doesn’t address individual business dynamics and vulnerability. This simplistic approach to achieving compliance bred dangerous complacence in many companies.
It’s an oft stated sentiment that discomfort is what precipitates change. So many organizations feel overly comfortable and complacent when they check some compliance boxes or deploy a shiny new security product. This may even work for awhile, and the absence of a visible compromise begets overconfidence. As another axiom goes, all companies have experienced compromise, some just don’t know it yet.
What this issue comes down to is knowing what is most at risk in your own organization and understanding fully how you are positioned to prevent compromise specific to your environment. Organizations need to understand what is different about their business apart from what the regulations and requirements cover. These are just as critical, if not more, to address.
Much like compliance regulations, security products out-of-the-box are designed and deployed to address the most common threats and risks across most customers. Without some customization and tuning, they don’t account for your specific environment. A specific example is in signatures and detections. Attackers can determine what security products are in an environment, and already know the standard alert lists. So, if an organization is relying on out-of-box signatures and definitions only, they are playing right into an attacker’s hands. By leveraging business logic and customization, an organization creates a major blind spot for attackers.
For an added layer of protection, consider placing “canaries” in the coalmine. More mature companies leverage deception to ferret out intrusions. Honeypots, Honeytokens or false accounts can entice an attacker to reveal themselves at the first whiff of activity.
Dealer’s poor choice
I intentionally left this category until the end because so many people put it first – as an excuse. The “blame the stupid user” crowd can be deafening. The reality is twofold. First, we can’t expect everyone to have the same ability to understand and identify social engineering. Second, attackers continue to find better and better ways to fool their prey, and there are plenty of examples of even the most seasoned security pros falling victim.
Another breach this year is sure to stay top of mind for years to come. MGM proved that the house doesn’t always win, when an attacker social engineered their way to take $30 million out of Sin City.
We need to help users, not shame them. As noted earlier, employing multiple authentication factors beyond, and in addition to credentials is imperative. Multi-factor Authentication (MFA) provides a key element to resisting phishing attempts – whether to backstop an inexperienced user, or to account for an errant click or a decision under duress. In addition to familiar rotating authentication codes, this category also includes deployment of technologies such as Public Key Cryptography, Biometrics, and Zero Trust architectures. Finally, understanding and activation of these measures is only getting more urgent, as the environment for social engineering is getting increasingly dangerous, with deepfakes and AI making detection of fraudulent requests much harder to discern.
About The Author
Original post here
