Addressing vulnerability management

Blog
  • 1621959888112-code.webp
    Anyone working in the information and infrastructure security space will be more than familiar with the non-stop evolution that is vulnerability management. Seemingly on a daily basis, we see new attacks emerging, and those old mechanisms that you thought were well and truly dead resurface with “Frankenstein” like capabilities rendering your existing defences designed to combat that particular threat either inefficient, or in some cases, completely ineffective. All too often, we see previous campaigns resurface with newer destructive capabilities designed to extort both from the financial and blackmail perspective.

    It’s the function of the “Blue Team” to (in several cases) work around the clock to patch a security vulnerability identified in a system, and ensure that the technology landscape and estate is as healthy as is feasibly possible. On the flip side, it’s the function of the “Red Team” to identify hidden vulnerabilities in your systems and associated networks, and provide assistance around the remediation of the identified threat in a controlled manner.

    Depending on your requirements, the minimum industry accepted testing frequency from the “Red Team” perspective is once per year, and typically involves the traditional “perimeter” (externally facing devices such as firewalls, routers, etc), websites, public facing applications, and anything else exposed to the internet. Whilst this satisfies the “tick in the box” requirement on infrastructure that traditionally never changes, is it really sufficient in today’s ever-changing environments ? The answer here is no.

    With the arrival of flexible computing, virtual data centres, SaaS, IaaS, IoT, and literally every other acronym relating to technology comes a new level of risk. Evolution of system and application capabilities has meant that these very systems are in most cases self-learning (and for networks, self-healing). Application algorithms, Machine Learning, and Artificial Intelligence can all introduce an unintended vulnerability throughout the development lifecycle, therefore, failing to test, address, and validate the security of any new application or modern infrastructure that is public facing is a breach waiting to happen. For those “in the industry”, how many times have you been met with this very scenario

    “Blue Team: We fixed the vulnerabilities that the Red Team said they’d found…” “Red Team: We found the vulnerabilities that the Blue Team said they’d fixed…”

    Does this sound familiar ?

    What I’m alluding to here is that security isn’t “fire and forget”. It’s a multi-faceted, complex process of evolution that, very much like the earth itself, is constantly spinning. Vulnerabilities evolve at an alarming rate, and unfortunately, your security program needs to evolve with it rather than simply “stopping” for even a short period of time. It’s surprising (and in all honesty, worrying) the amount of businesses that do not currently (and even worse, have no plans to) perform an internal vulnerability assessment. You’ll notice here I do not refer to this as a penetration test - you can’t “penetrate” something you are already sitting inside. The purpose of this exercise is to engage a third party vendor (subject to the usual Non-Disclosure Agreement process) for a couple of days. Let them sit directly inside your network, and see what they can discover. Topology maps and subnets help, but in reality, this is a discovery “mission” and it’s up to the tester in terms of how they handle the exercise.

    The important component here is scope. Additionally, there are always boundaries. For example, I typically prefer a proof of concept rather than a tester blundering in and using a “capture the flag” approach that could cause significant disruption or damage to existing processes - particularly in-house development. It’s vital that you “set the tone” of what is acceptable, and what you expect to gain from the exercise at the beginning of the engagement. Essentially, the mantra here is that the evolution wheel in fact never stops - it’s why security personnel are always busy, and CISO’s never sleep 🙂

    These days, a pragmatic approach is essential in order to manage a security framework properly. Gone are the days of annual testing alone, being dismissive around “low level” threats without fully understanding their capabilities, and brushing identified vulnerabilities “under the carpet”. The annual testing still holds significant value, but only if undertaken by an independent body, such as those accredited by CREST (for example).

    You can reduce the exposure to risk in your own environment by creating your own security framework, and adopting a frequent vulnerability scanning schedule with self remediation. Not only does this lower the risk to your overall environment, but also provides the comfort that you take security seriously to clients and vendors alike whom conduct frequent assessments as part of their Due Diligence programs. Identifying vulnerabilities is one thing, however, remediating them is another. You essentially need to “find a balance” in terms of deciding which comes first. The obvious route is to target critical, high, and medium risk, whilst leaving the “low risk” items behind, or on the “back burner”.

    The issue with this approach is that it’s perfectly possible to chain multiple vulnerabilities together that on their own would be classed as low risk, and end up with something much more sinister when combined. This is why it’s important to address even low-risk vulnerabilities to see how easy it would be to effectively execute these inside your environment. In reality, no Red Team member can tell you exactly how any threat could pan out if a way to exploit it silently existed in your environment without a proof of concept exercise - that, and the necessity sometimes for a “perfect storm” that makes the previous statement possible in a production environment.

    Vulnerability assessments rely on attitude to risk at their core. If the attitude is classed as low for a high risk threat, then there needs to be a responsible person capable of enforcing an argument for that particular threat to be at the top of the remediation list. This is often the challenge - where board members will accept a level of risk because the remediation itself may impact a particular process, or interfere with a particular development cycle - mainly because they do not understand the implication of weakened security over desired functionality.

    For any security program to be complete (as far as is possible), it also needs to consider the fundamental weakest link in any organisation - the user. Whilst this sounds harsh, the below statement is always true

    “A malicious actor can send 1,000 emails to random users, but only needs one to actually click a link to gain a foothold into an organisation”

    For this reason, any internal vulnerability assessment program should also factor in social engineering, phishing simulations, vishing, eavesdropping (water cooler / kitchen chat), unattended documents left on copiers, dropping a USB thumb drive in reception or “public” (in the sense of the firm) areas.

    There’s a lot more to this topic than this article alone can sanely cover. After several years experience in Information and Infrastructure Security, I’ve seen my fair share of inadequate processes and programs, and it’s time we addressed the elephant in the room.

    Got you thinking about your own security program ?


  • 1 Votes
    1 Posts
    35 Views

    It’s not often that I post anything on LinkedIn, but the post below caught my eye, and raised an eyebrow (to say the least) when I read it.

    Screenshot_2023-08-24-20-39-47-54_254de13a4bc8758c9908fff1f73e3725.jpg

    I typically remain impassive and neutral to most of these types of post as they are usually aimed at selling you something. However, the frankly absurd security advice here being offered was so bad, I found it hard to ignore and posted the below response

    Forgive me if I decide not to take any of your cyber security advice as all of the points you’ve raised are the entire point of phishing exercises. Do you really think a nefarious actor isn’t going to send emails that look just like this (mostly because they have succeeded elsewhere as others have highlighted)?

    Your profile states that you are the leader of a world class cyber security team, yet you offer really bad advice like this? This is exactly how all cyber security campaigns work and their effectiveness is blatantly obvious by the screenshot you posted.

    “Hurt feelings” are irrelevant when you are measuring the effectiveness of your cyber security program. As the primary defense in any organization, the security department needs to be in a position to detect and repel as many attacks as possible. The paradigm here being that an organization needs to stop thousands of these attacks getting through per day (probably way more) yet an attacker only needs one link to be clicked for their campaign to succeed.

    Employee security awareness should in fact be everything that the original poster claims it shouldn’t be. Just look at the success rate of previous campaigns which any decent training program is based on.

    The bottom line here is that I really don’t understand the reasoning for the original post. This guy claims to be the leader of a world class cyber security team, yet he decides to give poor advice like this?

    Speechless. And this is a so called professional?? We’re all doomed 😱

  • 4 Votes
    4 Posts
    73 Views

    @phenomlab said in TikTok fined £12.7m for misusing children’s data:

    Just another reason not to use TikTok. Zero privacy, Zero respect for privacy, and Zero controls in place.

    https://news.sky.com/story/tiktok-fined-12-7m-for-data-protection-breaches-12849702

    The quote from this article says it all

    TikTok should have known better. TikTok should have done better

    They should have, but didn’t. Clearly the same distinct lack of core values as Facebook. Profit first, privacy… well, maybe.

    Wow, that’s crazy! so glad I stayed away from it, rotten to the core.

  • 2 Votes
    3 Posts
    77 Views

    @crazycells exactly. Not so long ago, we had the Cambridge Analytica scandal in the UK. Meta (Facebook) seem to be the ultimate “Teflon” company in the sense nothing seems to stick.

  • 0 Votes
    1 Posts
    107 Views

    1622024819274-security1.webp

    If you are new to the security industry, then penetration testing may be one of those topics you are starting to look at in more detail. If you’ve been in the industry for a while, then you will already know (I hope) the importance of this particular exercise. Penetration testing and ongoing vulnerability assessments are essential given today’s risk of cyber crime and data breaches, and most clients when performing due diligence will probably ask when the your most recent test was conducted. If you’ve never completed a test, and your client asks the question, don’t be surprised if you detect a glimpse of a raised eyebrow, or even a loss of confidence - and ultimately a loss of business because of this.

    The mitigating factors here are risk and gap analysis. If you have multiple potential entry points into your network, be it intended, or unintended, a vulnerability scan should be completed at least once a year (my personal preference is once a quarter, but this depends on budget) to verify the security of endpoints exposed to the public. Such endpoints are typically firewalls, routers, and essentially, anything that is hosting an externally accessible service.

    What does a penetration test involve ?

    The main concept is the word “penetration”, meaning to enter. Be it lawfully, or illegal, the principle remains the same - if a device can be accessed, it needs to be tested. Most services that are public facing are designed to be entered, but what if the entity utilising such access decides to violate the intended purpose ? A hacker could circumvent your controls and gain access to other areas, or leverage a flaw in the system that negates the intended service. Such a compromise can either provide access to personally identifiable data, or make the affected system vulnerable to another form of attack. Before any testing is performed, the penetration testing company will need to sign an NDA (Non Disclosure Agreement). This protects both their client in the form of confidentiality, and their reputation. After all, if they do find a weakness, you wouldn’t want them telling everyone about it. This may seem glaringly obvious, but you will be unpleasantly surprised if you knew how many companies had been duped over the years by a fake penetration testing entity that actually turn out to be hackers !

    Any penetration testing company that is legitimate will be more than aware of the importance in terms of client confidentiality and security, and will normally make the NDA their first discussion point before even asking about your network. If any potential penetration testing company does not raise this point, or attempts to deviate when asked questions around confidentiality, they should immediately be treated as a risk, and certainly never provided privileged information about your network topology.

    Due diligence

    In all cases, you should check and verify the identity and integrity of any company before entering into any contractual agreement. My suggestion here is to only accept reviews or recommendations from people you can actually meet or speak to over the phone without the penetration testing company facilitating any meetings or phone calls on your behalf. This removes the potential for fraud, and reduces the overall risk.

    Testing scope

    The penetration test scope depends on the criteria predefined - If an external penetration test is conducted, then this will typically be limited to devices or services exposed to the internet. The usual practice is to provide a list of IP Address ranges and associated subnets, and allow the penetration testing company to “walk” these ranges looking for services. Additionally, if you are looking to conduct a test of your internal network, then (at least to me), this is not a penetration test, but a vulnerability assessment. Why ?

    Because if someone is already inside your network, you aren’t testing the ability to penetrate something you already have access to - you are testing to see how effective your internal infrastructure is

    Testing process

    The penetration testing company will begin by scanning all IP Addresses and subnets to see what will respond. If the tester finds an exposed service (normally one you’d expect in an ideal world), they will perform an array of tests against the address to determine (but not limited to)

    The type of device The operating system Device fingerprint What services are running What ports are open

    Once the penetration tester has this information, further interrogation is possible. This part of the exercise is often automated using custom tools and scripts - most of these are often enhanced by the penetration testing company themselves, which provides a unique testing style (more on why this is important later). For example, if the penetration tester finds SNMP exposed on a device, they will then attempt to exploit known vulnerabilities in the protocol in order to get the device to “cough up” other details it wouldn’t normally divulge. A weak SNMP configuration can expose the running configuration of a router for example, meaning that the attacker then gains intelligence about your network and adjacent devices.

    Such intelligence allows the penetration tester to leverage other vulnerability checks, and ultimately, they may gain access through a route you did not expect - or even know existed.

    Testing responsibilities

    The remit of a penetration tester is not to hack your network, steal data, or bring the infrastructure to it’s knees, but to expose and report vulnerabilities to their client in a responsible and professional manner. This is typically in the form of a confidential findings report that is delivered to a predefined and authorised contact within your company.

    Testing findings and exceptions

    If the penetration testing company finds a vulnerability or exploit that is considered high risk, then they are duty bound to inform you of this discovery within a predefined time frame. This varies depending on the severity of the issue or potential exploit. In cases such as this, the penetration testing company provide documentation on the steps taken to reproduce the vulnerability, and provide an example of what they were able to do by leveraging it. This provides the client with sufficient knowledge to prepare to rectify the issue before the main findings report is produced. Seeing as penetration testers have other clients, the report can take some time to compile, and they wouldn’t want you to have an unknown exploit in the report when it does finally arrive.

    The implications of high risk vulnerabilities are wide ranging, can cause significant reputation damage for the tester if unreported (although this is at the discretion of the tester to report if they deem it important enough), and worse, could be exploited if left unpatched.

    Testing report

    The report should be protected with a strong password, and be in a format that cannot easily be manipulated or altered. A secured PDF with the ability to edit removed is the preferred medium. The method of delivery should be as secure as possible to prevent it from falling into the wrong hands. An ideal solution is to provide the report via a Secure SFTP server, or encrypted email. Most penetration testers use certificates when sending email, and are secure by default.

    Remediation

    This part is up to you. A thorough and respectable penetration testing company will provide all relevant information in relation to the risk levels they have identified, and will also provide a means to work towards remediation. Depending on the issues identified, the remediation will obviously be different for each device in scope, or each vulnerability identified. In most cases, penetration testing companies offer a reduced rate for performing the same test against devices and vulnerabilities subject to remediation provided all steps have been completed within a defined time period - typically 30 days. Look at it this way - if you are presented with a report that shows your infrastructure (external and internal) alluding to a block of Swiss Cheese and you chose to ignore it, then you deserve to be hacked in my view. Harsh ? Yes. A reality ? Very much so. Ignore vulnerabilities at your peril.

    Look at it this way - it’s much easier to avoid spilling milk in the first place than it is to mop it up afterwards

    Should I perform my own testing ?

    Yes, but your test results could be seen as one sided, or biased given that you have conducted the test yourself. My advice here would be

    Perform your own interim testing. The frequency really depends on attitude to risk, I personally consider once a quarter as a sane value Complete remediation as far as possible, and perform as much post-testing as you can to identify any further risk Engage a recognised penetration testing company to carry out their own independent testing to validate and confirm your remediation

    The report generated by this entity will carry much more weight, and can be used for client evidence if they request it. There’s much more to this topic, so if you’d like any further information, just ask - I’ll be more than happy to answer questions.

  • 1 Votes
    1 Posts
    148 Views

    1622031373927-headers-min.webp

    It surprises me (well, actually, dismays me in most cases) that new websites appear online all the time who have clearly spent an inordinate amount of time on cosmetics / appearance, and decent hosting, yet failed to address the elephant in the room when it comes to actually securing the site itself. Almost all the time, when I perform a quick security audit using something simple like the below

    https://securityheaders.io

    I often see something like this

    Not a pretty sight. Not only does this expose your site to unprecedented risk, but also looks bad when others decide to perform a simple (and very public) check. Worse still is the sheer number of so called “security experts” who claim to solve all of your security issues with their “silver bullet” solution (sarcasm intended), yet have neglected to get their own house in order. So that can you do to resolve this issue ? It’s actually much easier than it seems. Dependant on the web server you are running, you can include these headers.

    Apache <IfModule mod_headers.c> Header set X-Frame-Options "SAMEORIGIN" header set X-XSS-Protection "1; mode=block" Header set X-Download-Options "noopen" Header set X-Content-Type-Options "nosniff" Header set Content-Security-Policy "upgrade-insecure-requests" Header set Referrer-Policy 'no-referrer' add Header set Feature-Policy "geolocation 'self' https://yourdomain.com" Header set Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()" Header set X-Powered-By "Whatever text you want to appear here" Header set Access-Control-Allow-Origin "https://yourdomain.com" Header set X-Permitted-Cross-Domain-Policies "none" Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" </IfModule> NGINX add_header X-Frame-Options "SAMEORIGIN" always; add_header X-XSS-Protection "1; mode=block"; add_header X-Download-Options "noopen" always; add_header X-Content-Type-Options "nosniff" always; add_header Content-Security-Policy "upgrade-insecure-requests" always; add_header Referrer-Policy 'no-referrer' always; add_header Feature-Policy "geolocation 'self' https://yourdomain.com" always; add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=();"; add_header X-Powered-By "Whatever text you want to appear here" always; add_header Access-Control-Allow-Origin "https://yourdomain.com" always; add_header X-Permitted-Cross-Domain-Policies "none" always; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;" always;

    Note, that https://yourdomain.com should be changed to reflect your actual domain. This is just a placeholder to demonstrate how the headers need to be structured.

    Restart Apache or NGINX, and then perform the test again.


    That’s better !

    More detail around these headers can be found here

    https://webdock.io/en/docs/how-guides/security-guides/how-to-configure-security-headers-in-nginx-and-apache

  • 0 Votes
    1 Posts
    140 Views

    1622032930658-hacked_listen-min.webp

    I’ve been a veteran of the infosec industry for several years, and during that time, I’ve been exposed to a wide range of technology and situations alike. Over this period, I’ve amassed a wealth of experience around information security, physical security, and systems. 18 years of that experience has been gained within the financial sector - the remaining spread across manufacturing, retail, and several other areas. I’ve always classed myself as a jack of all trades, and a master of none. The real reason for this is that I wanted to gain as much exposure to the world of technology without effectively “shoehorning” myself - pigeon holing my career and restricting my overall scope.

    I learned how to both hack and protect 8086 / Z80 systems back in 1984, and was using “POKE” well before Facebook coined the phrase and made it trendy (one of the actual commands I still remember to this day that rendered the CTRL, SHIFT, ESC break sequence useless was

    POKE &bdee, &c9

    I spent my youth dissecting systems and software alike, understanding how they worked, and more importantly, how easily they could be bypassed or modified.

    Was I a hacker in my youth ? If you understand the true meaning of the word, then yes - I most definitely was.

    If you think a hacker is a criminal, then absolutely not. I took my various skills I obtained over the years, honed them, and made them into a walking information source - a living, breathing technology encyclopedia that could be queried simply by asking a question (but not vulnerable to SQL injection).

    Over the years, I took an interest in all forms of technology, and was deeply immersed in the “virus era” of the 2000’s. I already understood how viruses worked (after dissecting hundreds of them in a home lab), and the level of damage that could be inflicted by one paved the way for a natural progression to early and somewhat infantile malware. In its earliest form, this malware was easily spotted and removed. Today’s campaigns see code that will self delete itself post successful execution, leaving little to no trace of its activity on a system. Once the APT (Advanced Persistent Threat) acronym became mainstream, the world and its brother realised they had a significant problem in their hands, and needed to respond accordingly. I’d realised early on that one of the best defences against the ever advancing malware was containment. If you “stem the flow”, you reduce the overall impact - essentially, restricting the malicious activity to a small subset rather than your entire estate.

    I began collaborating with various stakeholders in the organisations I worked for over the years, carefully explaining how modern threats worked, the level of damage they could inflict initially from an information and financial perspective, extending to reputation damage and a variety of others as campaigns increased in their complexity). I recall one incident during a tenure within the manufacturing industry where I provided a proof of concept. At the time, I was working as a pro bono consultant for a small company, and I don’t think they took me too seriously.

    Using an existing and shockingly vulnerable Windows 2003 server (it was still using the original settings in terms of configuration - they had no patching regime, meaning all systems were effectively vanilla) I exhibited how simple it would be to gain access first to this server, then steal the hash - effortlessly using that token to gain full access to other systems without even knowing the password (pass the hash). A very primitive exercise by today’s standards, but effective nonetheless. I explained every step of what I was doing along the way, and then explained how to mitigate this simple exploit - I even provided a step by step guide on how to reproduce the vulnerability, how to remediate it, and even provided my recommendations for the necessary steps to enhance security across their estate. Their response was, frankly, shocking. Not only did they attempt to refute my findings, but at the same time, dismissed it as trivial - effectively brushing it under the carpet so to speak. This wasn’t a high profile entity, but the firm in question was AIM listed, and by definition, were duty bound - they had a responsibility to shareholders and stakeholders to resolve this issue. Instead, they remained silent.

    Being Pro Bono meant that my role was an advisory one, and I wasn’t charging for my work. The firm had asked me to perform a security posture review, yet somehow, didn’t like the result when it was presented to them. I informed them that they were more than welcome to obtain another opinion, and should process my findings as they saw fit. I later found out through a mutual contact that my findings had been dismissed as "“unrealistic”, and another consultant had certified their infrastructure as “safe”. I almost choked on my coffee, but wrote this off as a bad experience. 2 months later, I got a call from the same mutual contact telling me that my findings were indeed correct. He had been contacted by the same firm asking him to provide consultancy for what on the face of it, looked like a compromised network.

    Then came the next line which I’ll never forget.

    “I don’t suppose you’d be interested in……”

    I politely refused, saying I was busy on another project. I actually wasn’t, but refused out of principle. And so, without further ado, here’s my synopsis

    “…if you choose not to listen to the advice a security expert gives you, then you are leaving yourself and your organisation unnecessarily vulnerable. Ignorance is not bliss when it comes to security…”

    Think about what you’ve read for a moment, and be honest with me - say so if you think this statement is harsh given the previous content.

    The point I am trying to make here is that despite sustained effort, valiant attempts to raise awareness, and constantly telling people they have gaping holes in systems for them to ignore the advice (and the fix I’ve handed to them on a plate) is extremely frustrating. Those in the InfoSec community are duty bound to responsibly disclose, inform, educate, raise awareness, and help protect, but that doesn’t extend to wiping people’s noses and telling them it wasn’t their fault that they failed to follow simple advice that probably could have prevented their inevitable breach. My response here is that if you bury your head in the sand, you won’t see the guy running up behind you intent on kicking you up the ass.

    Security situations can easily be avoided if people are prepared to actually listen and heed advice. I’m willing to help anyone, but they in return have to be equally willing to listen, understand, and react.

  • 0 Votes
    1 Posts
    151 Views

    1631808994808-scamming.jpg.webp

    One of many issues with working in the Infosec community is an inevitable backlash you’ll come across almost on a daily basis. In this industry, and probably hundreds of others like it are those who have an opinion. There’s absolutely nothing wrong with that, and it’s something I always actively encourage. However, there’s a fine line between what is considered to be constructive opinion and what comes across as a bigoted approach. What I’m alluding to here is the usage of the word “hacker” and it’s context. I’ve written about this particular topic before which, so it seems, appears to have pressed a few buttons that “shouldn’t be pressed”.
    alt text

    But why is this ?

    The purpose of this article is definition. It really isn’t designed to “take sides” or cast aspersions over the correct usage of the term, or which scenarios and paradigms it is used correctly or incorrectly against. For the most part, the term “hacker” seems to be seen as positive in the Infosec community, and based on this, the general consensus is that there should be greater awareness of the differences between hackers and threat actors, for example. The issue here is that not everyone outside of this arena is inclined to agree. You could argue that the root of this issue is mainly attributed to the media and how they portray “hackers” as individuals who pursue nefarious activity and use their skills to commit crime and theft on a grand scale by gaining illegal access to networks. On the one hand, the image of hoodies and faceless individuals has created a positive awareness and a sense of caution amongst the target groups – these being everyday users of civilian systems and corporate networks alike, and with the constant stream of awareness campaigns running on a daily basis, this paradigm serves only to perpetuate rather than diminish. On the other hand, if you research the definition of the term “hacker” you’ll find more than one returned.

    Is this a fair reflection of hackers ? To the untrained eye, picture number 2 probably creates the most excitement. Sure, picture 1 looks “cool”, but it’s not “threatening” as such, as this is clearly the image the media wants to display. Essentially, they have probably taken this stance to increase awareness of an anonymous and faceless threat. But, it ISN’T a fair portrayal.

    Current definitions of “the word”

    The word “hacker” has become synonymous with criminal activity to the point where it cannot be reversed. Certainly not overnight anyway. The media attention cannot be directly blamed either in my view as without these types of campaigns, the impact of such a threat wouldn’t be taken seriously if a picture of a guy in a suit (state sponsored) was used. The hoodie is representative of an unknown masked assailant and it’s creation is for awareness – to those who have no real understanding of what a hacker should look like – hence my original article. As I highlighted above, we live in a world where a picture speaks a thousand words.

    The word hacker is always going to be associated with nefarious activity and that’s never going to change, regardless of the amount of effort that would be needed to re-educate pretty much the entire planet. Ask anyone to define a hacker and you’ll get the same response. It’s almost like trying to distinguish the deference between a full blown criminal and a “lovable rogue” or the fact that hoodies aren’t trouble making adolescent thugs.

    Ultimately, it’s far too ingrained – much like the letters that flow through a stick of rock found on UK seaside resorts. It’s doesn’t matter how much you break off, the lettering exists throughout the entire stick regardless if you want that to happen or not. To make a real change, and most importantly, have media (and by definition, everyone else) realise they have made a fundamental misjudgement, we should look at realistic definitions.

    The most notable is the below, taken from Tech Target

    A hacker is an individual who uses computer, networking or other skills to overcome a technical problem. The term hacker may refer to anyone with technical skills, but it often refers to a person who uses his or her abilities to gain unauthorized access to systems or networks in order to commit crimes. A hacker may, for example, steal information to hurt people via identity theft, damage or bring down systems and, often, hold those systems hostage to collect ransom.

    The term hacker has historically been a divisive one, sometimes being used as a term of admiration for an individual who exhibits a high degree of skill, as well as creativity in his or her approach to technical problems. However, the term is more commonly applied to an individual who uses this skill for illegal or unethical purposes.

    One great example of this is that hackers are not “evil people” but are in fact industry professionals and experts who use their knowledge to raise awareness by conducting proof of concept exercises and providing education and awareness around the millions of threats that we are exposed to on an almost daily basis. So why does the word “hacker” strike fear into those unfamiliar with its true meaning ? The reasoning for this unnecessary phenomena isn’t actually the media alone (although they have contributed significantly to it’s popularity). It’s perception. You could argue that the media have made this perception worse, and to a degree, this would be true. However, they actually didn’t create the original alliance – the MIT claimed that trophy and gave the term the “meaning” it has to this day. Have a look at this

    MIT Article

    Given the origins of this date back to 1963, the media is not to blame for creating the seemingly incorrect original reference when it’s fairly obvious that they didn’t. The “newspaper” reflected in the link is a campus circulation and was never designed for public consumption as far as I can see. Here’s a quote from that article:

    “Many telephone services have been curtailed because of so-called hackers, according to Professor Carleton Tucker, administrator of the Institute telephone system.

    The students have accomplished such things as tying up all the tie-lines between Harvard and MIT, or making long-distance calls by charging them to a local radar installation. One method involved connecting the PDP-1 computer to the phone system to search the lines until a dial tone, indicating an outside line, was found.”

    The “so-called hackers” alignment here originally comes from “Phreaking” – a traditional method of establishing control over remote telephone systems allowing trunk calls, international dialling, premium rates, etc, all without the administrator’s knowledge. This “old school” method would certainly no longer work with modern phone systems, but is certainly “up there” with the established activity that draws a parallel with hacking.

    Whilst a significant portion of blogs, security forums, and even professional security platforms continue to use images of hoodies, faceless individuals, and the term “hacker” in the criminal sense, this is clearly a misconception – unfortunately one that connotation itself has allowed to set in stone like King Arthur’s Excalibur. In fairness, cyber criminals are mostly faceless individuals as nobody can actually see them commit a crime and only realise they are in fact normal people once they are discovered, arrested, and brought to trial for their activities. However, the term “hacker” is being misused on a grand scale – and has been since the 1980’s.

    An interesting observation here is that hoodies are intrinsically linked to threatening behaviour. A classic example of this is here. This really isn’t misrepresentation by the media in this case – it’s an unfortunate reality that is on the increase. Quite who exactly is responsible for putting a hacker in a hoodie is something of a discussion topic, but hackers were originally seen as “Cyberpunks” (think Matrix 1) until the media stepped in where they suddenly were seen as skateboarding kids in hoodies. And so, the image we know (and hackers loathe) was born. Perhaps one “logical” perspective for hoodies and hackers could be the anonymity the hoodie supposedly affords.

    The misconception of the true meaning of “hacker” has damaged the Infosec community extensively in terms of what should be a “no chalk” line between what is criminal, and what isn’t. However, it’s not all bad news. True meaning aside, the level of awareness around the nefarious activities of cyber criminals has certainly increased, but until we are able to establish a clear demarcation between ethics in terms of what is right and wrong, those hackers who provide services, education, and awareness will always be painted in a negative light, and by inference, be “tarred with the same brush”. Those who pride themselves on being hackers should continue to do so in my view – and they have my full support.

    It’s not their job solely to convince everyone else of their true intent, but ours as a community.

    Let’s start making that change.

  • 2 Votes
    12 Posts
    501 Views