Have you ever wondered what are hackers like, where they are based, and what are they thinking?
They are human like everyone else – you wouldn’t be able to tell a hacker from a regular programmer. But they are often extremely smart software engineers who understand how the world of IT works, invariably a lot better than an average developer, so it’s no wonder that sometimes they end up being employed by government agencies.
Ethical hackers are helping build our defenses against data breaches and cybercrime, protect privacy, and restore trust about the digital landscape. Unfortunately, there are hackers that use their intelligence for malicious purposes and are occasionally influenced by ideologies or motivations that are not widely accepted. They leverage malware, hacking tools, and stolen identity documents from the dark web to penetrate companies’ systems.
Hackers operate across all geographies, but our systems at BOS Framework see most hacker attacks from China, Russia, Pakistan, and North Korea. This could be a strategic “counter alliance” in a bid to push for a greater bipolarity in world affairs. But with many of these geographies representing large low-income populations, hacking can appear to be a lucrative alternative.
Although some hackers are state sponsored for political reasons or work for terrorist organizations, they usually work for themselves and collect ransoms. For some hackers, breaking into forbidden places may simply seem like a fun pastime.
Fractured architecture from a hacker’s perspective
A typical company doesn’t have a single application – they have many, built over many years, by various people without a common architecture standard, creating a constantly changing landscape of technologies, infrastructure, and processes.
These applications are comprised of many layers: the front-end, the web or mobile application that the end-user interacts with, the APIs, the databases, and the various servers where applications and databases are hosted. The communications and data flow through this ecosystem should follow the correct principles by being transient and privilege-based, called network isolation control. For example, when users log in by entering their login credentials from the front-end, they will have specific privileges that will only allow selective access to certain data.
Developers are invariably specialists for only the front-end, API development, or databases. Their ability to perceive the entire system as one whole is somewhat challenged by their role in the organization and by their limitations of systemic understanding.
Typically, developers identify a problem and look for the simplest and fastest solution possible (patch-by-patch formula) without having the full context. A developer’s primary focus is on user experience or the quality of the application. If the immediate customer is satisfied, not through security but by delivering functionality, the company is unconcerned.
Furthermore, developers are not always trained on security and compliance, and security officers have little input on protocol or policy. Security teams only retroactively review applications and ecosystem security when systems are already in production – by that time, it is already too late.
What should be ingrained into the company DNA has become an after-the-fact consideration. If you have an infinite number of holes on a boat, it will eventually sink – that’s why companies are becoming obvious targets for hackers.
The key takeaway here is that any system built prior to 2019 will most likely have a very different architecture and underlying standard compared to what is needed today, given the increased escalation of cyber incidents. Most systems have not been designed to follow best practices such as distributed applications and data, the separation of protected health information (PHI) and personally identifiable information (PII), and strong observability, visibility, and traceability. Now is the time.
How hackers look for weaknesses on a day-to-day basis
The disconnect between security, developer, and operation teams isn’t necessarily visually represented. But the hacker is looking at the entire ecosystem for any possible vulnerability or disconnect to exploit. If a vulnerability appears to repeat itself in various areas in the ecosystem – across the authentication, authorization, databases, servers, and logging systems – and a hacker has already exploited one area, they will be able to package up their findings as a program and deploy it at scale.
There isn’t a comprehensive way to test security weaknesses. Certain tools have security scans and penetration tests, but they are generic in nature, like end-point protection or activity logs. There are many tests for functionality which is more discoverable, but security concerns are often only revealed when there’s an actual incident. The hacker knows that this problem exists, and they are searching for new systems that have not been tested yet. Therefore, they are interested in your development, demo, beta, and production environments.
Hackers are not bound by rules nor controls. They use automation, targeted programming, and various combinations of techniques to look for weaknesses in the code, databases, and infrastructure to unlock company defenses. Their automation routines keep working as they sleep.
Segmenting and distributing data puts hackers off
Security and resilience can only result from sound architecture that is based on best practices. A successful set-up is never about a single application: it should be viewed as the connective tissue that brings together a distributed ecosystem – intentionally designed to break different types of data, like PHI, PII, and financial data into smaller units.
Companies should never have data centralized in one location. Dispersal reduces the blast radius of a data breach. The data becomes useless by itself, and hackers cannot hold any piece of this data out for ransom unless they gather all the other important information at the same time.
Even as IT employment skyrockets and the IoT security testing market grows, especially SIEM and SOAR, it is unlikely that a hacker’s job will get harder. As more and more people take on employment, there will be less and less standardization, making it more exciting for hackers.
When a hacker doesn’t have to work for anyone and can be a self-employed “entrepreneur”, you can see why the job is so appealing. Hackers will always be present, like viruses, and they will always be able to enter systems. So, instead of creating defenses or resistance that are unbreachable, we must create breach resilience, redundancies, and auto-recovery capabilities.
Credit: Source link
