Hey there Security Professional…..How do YOU mitigate attacks?
The last several months have been historic by any measure. U.S. banks and financial institutions around the world have come under cyber-attacks at a high rate. We’ve seen everything from DDoS attacks to waves of ransomware.
So, why was this? Is it because they didn’t have enough resources or serious professionals dedicated to program management? Not likely. The true answer is a bit more uncomfortable, but worthy of exploration.
The true reason is that attack mitigation is not a core competency of modern day security programs.
For example: Have you, Mr. or Mrs. Security Professional, ever tested your environment for a cyber attack? Do you know how to mitigate these animals (no these are not modern-day Pen Tests, which don’t test ‘service disrupting techniques’)?
Does this question seem strange? If it does, why? If it doesn’t, do you have a clear and concise answer to this question?
Now let’s change that question. Suppose we said, how do you mitigate vulnerabilities? Ah, that question is easier to answer, more comfortable.
Ok (humor me a little longer), suppose we now asked, what tools and technology do you leverage to mitigate today’s threats? Oh, this one is easy.
Hmmm, have you noticed that today’s risks are not about individual threats or single vulnerabilities, but rather a cacophony of trialed threat and exploit vectors – – something we term as an “attack?”
So, given the fact that the cyber security world has changed over the past two years to an attack-based model which has its own new attributes, have you changed to adapt your control infrastructure to these new techniques?
So, here’s the call to action: it’s high time we begin the process of not only dealing with individual vulnerabilities, but also diving deep into popular attack types, schemes, and tools (e.g. platforms) so that we might be able to prepare ourselves with better and more competent responses. Yes, attacks are unique and represent a new entrant in the dealings of information security programs. So, let me explain this concept deeper via the picture below. As you notice, if we just take the information security domain of availability-based problems, as opposed to the confidentiality or integrity domains, we can clearly see how vulnerabilities correlate with common attacks. However, also notice that attacks are normally complicated ‘recipes’ of attempts to exploit both known and unknown (only make preconceived responses to the numerous attack techniques or recipes successfully leveraged against).
Point One: Tomorrow’s Risks are Here Today.
– Hacktivist Cyberattacks / Anti-DoS
– Zero-Day Threats / Polymorphic Malware
– Social Engineering Risks
– Application-Level Vulnerabilities
– Next-Generation DoS (e.g. HTML 5, ReDos, AJAX Injection, etc.
Point Two: Have you been able to integrate a risk model to address these threats?
– Next Generation Architecture (NG AV, NG Perimeter Defense, NG FW, Zoning)
– Next Generation Forensics (Netflow, PCAP, Signaling, etc)
– Next Generation Defense – Counter Attack Concepts
Point Three: Security is hard, exploring the “tough questions” in your environment will expose risks better than today’s standards-based and compliance-based models.
As we continue into 2017, I can’t help but be astonished on how effective attacks by hacktivist group Anonymous have been. Vast majorities of targeted organizations have been left licking their wounds and posthumously responding to numerous queries on what happened and why they weren’t protected.
In fact, the perpetrators of these effective attacks have gotten used to just suggesting that they are going to be angry at an organization in order to get their desired behavioral changes. This was notable when they put Sony, GoDaddy and Nintendo on their target lists for supporting the proposed U.S. Privacy Act (SOPA) only to have each of these companies publically change their positions to reduce the risk of attacks.
So, given the efficacy of Anonymous and other hacktivist organizations over the past few years, I thought I would take a stab at highlighting the top six key attributes Anonymous looks to exploit in targeted victims:
1. Failure to Consider Security-Related Availability Threats. Every certified information security professional understands the principle that ALL security-related activities need to be accomplished in pursuit of one or more of the following: Confidentiality (e.g. Privacy), Integrity and / or Availability. That is, security is DRIVEN by one or more of these principles. It is also no secret that over the past ten years, nearly all security professionals have become intimately engaged with the concepts, theorems and infrastructures required to protect organizations from Privacy and / or Confidentiality leaks, however most of these security professionals have never either thought about or experienced an availability-based security problem. This availability-based threat, or what we call “attacks” is largely a foreign concept requiring different behavior, infrastructure, reporting and actions. Therein lies the problem and opportunity for hacktivists! Anonymous loves the fact that scores of security professionals fail to realize just how vulnerable their organization is to an outage from simple volumetric threats!
2. Overreliance on Cloud / ISP Scrubbing Capabilities. “Sign up with your telecom provider and done” has been the philosophy for so many organizations for years that the idea of scrubbing enterprise-level data centers has been a remote concept. In fact, so many companies have considered DDoS a check box fulfilled by their Internet Service Providers (ISPs) that they paid very little attention to both the complexity or severity of the threat until recently. Well, instead of technically illustrating how insufficient cloud-based DDoS scrubbing is in today’s world, I will leave with you the illustrations of legions of organizations who were both customers of ISP scrubbers and today have suffered some at the very least, embarrassing, and the very worst, debilitating outages and loss of institutional product and service integrity.
3. Never Tested Internal Availability Protections / Vulnerabilities. “Conduct the Vulnerability Assessment without Causing Service Disruption.” That’s the verbiage most contracts use when being signed by information security consultants. In other words, conduct a vulnerability assessment; however please don’t evaluate our ‘availability’ vulnerabilities. Everyone knows that for years, organizations have been testing their control infrastructure in almost every way imaginable. They have been conducting technical assessments such as Penetration Tests, Network and Application Vulnerability Assessments, Code Reviews, Architecture Engineering Assessments, etc. They have also tested compliance against regulations and best practices such as GLBA, HIPAA, SOX, PCI, ISO 27001/2, HIPAA HiTECH, etc. However, what most people don’t realize is that nearly all of the results of these tests were evaluating security programs and models against threats represented by integrity and confidentiality based attacks, not availability attacks. In fact, to prove this point even further, most modern day vulnerability scanners have either removed ‘invasive’ or availability-based scans from their initial scan profiles, or have made the scans very difficult to launch by a lay person. This has resulted in a mass of organizations who are blissfully ignorant to the vulnerabilities associated with availability attacks (e.g. malformed UDP floods, dictionary attacks, brute-force attacks, HTTP POST attacks, etc.) and the probability of success of said attacks.
4. Inability to Triage Attack for Effective Matching of Priority-Matched Mitigation. As illustrated in the graphic below, attacks come in multiple layers and frequently in complex (e.g. many vulnerabilities packaged into one lengthy attack). Although most ISPs and Service Providers have established models to ‘scrub their pipes,’ most enterprise security models do not adhere to this model and instead are set up to address each attack sequentially and without a priority assessment to properly allocate resources. Anonymous knows that enterprises suffer from this ‘volumetric’ attack profile and frequently bury numerous vulnerabilities into attacks with the assumptions that normal enterprises cannot distinguish between the attack types (e.g. SYN ACK floods with a SQL injection attack – ref: Sony Attacks).
5. Over-reliance on tools – not talent (Static Perimeter Protection Model). We all know that tools will eventually fail us – they don’t evolve quickly to match a changed landscape. As with all tools, the assumptions which go into the model are often the first attack vector for a perpetrator. For example, if the enterprise does Data Loss Prevention, well then, just encrypt the traffic and this way you get around the data scrubbing model. When dealing with integrity or confidentiality a company has the luxury of after-action analysis and forensics, however when dealing with ‘availability-based ‘attacks, organizations don’t have the luxury of long-drawn out forensic analysis. The capability to determine what is going well, and what is not going well needs to be determined in real time, which means that the deployed detection and mitigation tool set needs to be closely aligned with expert technicians and engineers who can properly configure and reconfigure the tools to avoid and disrupt emerging and changing threat landscapes. Moreover, as illustrated in the slide below, expert skills in the “availability security” disciplines of Network Behavioral Analysis, DDoS Prevention, and Web Application Firewalls are in serious deficits. Hacktivists around the world understand this concept and bank on companies having no intelligent resources to counteract their advancing and evolving techniques. Organizations require instant access to a team of supremely talented individuals – – something we call our Emergency Response Team (ERT)!
6. Failure to recognize / understand application-layer threats. Application-level is Pandora’s box for hacktivists. Just to give you a quick example of the types of understanding of the complexity of application-layer threats, the following is a list of the questions in which all application-layer security professionals must have on hand AFTER reviewing application vulnerabilities and protection mechanisms about their applications at all times to ensure proper AVAILABILITY of their operations.
How many web servers\web applications?
What type of web applications?
How many active connections?
What are the current idle time settings for every web application?
How Many Transactions per Second?
Is acceleration such as a caching used?
Does the web sites are public or via CDN?
What is the required CPS?
Does the application leverage caching or not?
Is a response check needed (e.g. Safe Reply filter)?
Anonymous understands how difficult it is to not only assess the vulnerabilities to a website, but also to run the website in a secure manner without making the site susceptible to a DDoS attack!