Navigating the Rapid Digital Shift: Ticket on the Bus, Not the Whole Bus

Global Companies’ Evaluation of Cybersecurity Solutions Selection Has Been Steadily Changing 

If it wasn’t already obvious to cybersecurity sales teams, there’s been a sea change for large organizations evaluating and buying new security products to protect their businesses. Responding to COVID-19, transformation plans that enable “work from home” such as Zero Trust identity and access management have been greatly accelerated, while technology refreshes and other capital-intensive plans are being pushed back.

Now, several months into this new operations paradigm, there may be added credence to the adage “in for a penny, in for a pound.” 

Many large companies have successfully navigated the digital shift to most of their workforce working remotely, finding the transition less difficult than first envisaged and achieving higher productivity than anticipated. Because such companies have resolved long-held internal conflicts over the security and integrity of cloud-based business operations, many of those postponed capital-intensive projects are being reviewed with a cloud-enabled, subscription-based lens.

This has several ramifications for cybersecurity vendors—particularly the specialized boutiques and innovative startups looking to quickly capitalize on new security opportunities.

Global companies’ evaluation of cybersecurity solutions selection has been steadily changing over the past couple years. The rapid digital shift of recent months has reinforced the need for change. 

I’d like to offer advice to vendors attempting to reach out and position their new cybersecurity products.

1. “I’ll buy a ticket, not the whole bus.” For decades, startups have looked to the largest companies as the Golden Goose and focused great energies in selling into them. The premise being that by solving a critical problem for them at a very high premium, that will cover the costs of developing an actual solution that can be sold broadly—e.g., the sale will fund my company’s product development. Although there may be a few cases where only a custom-tuned solution is required, many large businesses now prefer to buy a close-enough solution off the rack and work with the vendor as an advisor—not an investor. CISOs are looking at the sustainable list price of the solution and will purchase at a discounted level proportional to their deployment’s scale.
2. “Cost projection is critical.” Although highly versatile and scalable, cloud-based services billing can be difficult to predict—especially if the cybersecurity solution requires multiple third-party and cloud-provider SaaS dependencies. Security owners and budget holders are requiring vendors to provide accurate billing forecast and tiered discount models for the complete solution—models that include all dependent service costs (e.g., log storage analytics, container management). Vendors need to remove as much calculus from the pricing as possible and be prepared for billed services to be pared back if overly optimistic projections exceed the planned budget. Cost discussions have replaced those about cloud solutions prices.
3. “Features must be pre-integrated.” If the product is a feature (which, let’s face it, almost all new startup products are!), recognize it as a feature and don’t position it as a partial solution. As a feature product, integration with the solutions businesses already use is a prerequisite, and sales representatives should lead with the integration and interoperability first. CISOs are looking to shrink their attack surface and simplify the portfolio of products and vendors they rely on, and are increasingly reluctant to take on the task of brokering partnership between vendors as a prerequisite for extracting new protection value. Feature products benefit greatly by being enabled from within a solution provider’s product or marketplace.

On a related note, with the surge to execute day-to-day business operations remotely with a diverse and globally distributed workforce, cybersecurity buying decisions will increasingly factor accessibility, usability, and inclusiveness in solution design and operability. Vendors will be steered toward cloud-standardized accessibility interfaces—enabling visually impaired employees to use screen readers or dexterity-limited users to employ voice-to-text controls—to perform their analysis.

These changes are not unique to the largest enterprise businesses and are trickling down to other educated cybersecurity buyers feeling the same buying pain. Forewarned is forearmed.

-- Gunter Ollmann

First Published: SecurityWeek - June 9, 2020

Retooling Cyber Ranges

Cloud-based Cyber Ranges Will Change the Future of Training and Certifying Security and DevOps Professionals

A half-decade ago, with much fanfare, cyber ranges were touted as a revolutionary pivot for cybersecurity professionals’ training. Many promises and investments were made, yet the revolution has been slow coming. What may have been a slow start appears to be picking up speed and, with the accelerated adoption of work-from-home business practices, may finally come of age.

The educational premise behind almost all cyber range training platforms is largely unchanged from decades-old war-gaming and capture the flag—nothing beats hands-on practice in refining attack and defense strategies or building responder muscle memory. Carefully scripted threat scenarios guide the training program—often gamifying the experience with mission scores and leaderboards. Many of the interfaces and scenario scene-setting often appear like they came from the imagination of developers who grew up on a diet of 1990’s video games like Command & Conquer; the militaristic adversary overtone is strong yet adds positively to the immersive experience for users.

For many years, gamified security training has required significant infrastructure investment by the provider—investments capable of replicating the complex environments of their customers and the apparatus to generate realistic network traffic. Like the customers that subscribe, cyber-range platforms are undergoing their own digital transformation and moving to the cloud—ephemeral virtual environments, dynamic scaling to the number of participants, global anytime delivery, etc., are all obvious advantages to building and running cyber ranges within the public cloud.

What may be less obvious is how cloud-based cyber ranges will change the future of training and certifying security and DevOps professionals.

Some of the changes underway (and maybe a couple years down the road for mainstream availability) that excite me include:

• At-home cyber-range training and hands-on mastery of operational security tasks and roles. Past cyber-range infrastructure investments necessitated classroom-based training or regional traveling roadshows. Cloud-based cyber ranges can remove the physical classroom and scheduling constraints—offering greater flexibility for employees to advance practical skills at their own pace and balance time investments against other professional and personal commitments. I’m particularly encouraged with the prospect of delivering a level field for growing and assessing the practical skills and operational experiences of security professionals coming from more diverse backgrounds.
• Train against destructive scenarios within your own business environment. As businesses run more of their critical systems within the cloud, it becomes much easier to temporarily spin up a clone, mirror, or duplicate of that environment and use it as the basis for potentially destructive training scenarios. Cyber ranges that apply threat scenarios and gamify the training regime for users across the replicated workloads of their customers significantly increase the learning value and response applicability to the business.
• Shift-left for security mastery within DevOps. Cyber range environments and the scenarios they originally embraced focused on security incident responders and SOC operators—the traditional Blue Team members. With security becoming a distributed responsibility, there is a clear need to advance from security awareness to hands-on experience and confidence for a broader range of cyber-professional. Just as SIEM operations have been a staple of cyber ranges, a new generation of cyber-range platforms will “shift left” to replicate the complex CI/CD environments of their customers—enabling DevOps teams to practice responding to zero-day bugs in their own code and cascading service interruptions, for example.

It will be interesting to see how enterprise SOC leaders will embrace SecOps teams that trained and certified via cyber ranges at home. I’m sure many CISOs will miss the ability to escort senior executives, investors, and business partners around a room filled with security professionals diligently staring at screens of graphs and logs, and a wall of door-sized screens showing global pew-pew animated traffic flows. 

There is a difference between a knowledge certificate and the confidence that comes with hands-on experience—and that confidence applies not only to the employee, but to their chain of command.

The coming of age for cyber ranges is both important and impactful. It is important that we can arm a greater proportion and more diverse range of cyber-professionals with the hands-on practical experience to tackle real business threats. It is impactful because cyber-range scenarios provide real insights into an organization’s capabilities and resilience against threats, along with the confidence to tackle them when they occur.

-- Gunter Ollmann

First Published: SecurityWeek - March 31, 2020

Changing the Disclosure Shame Culture

For Cyber-defense to Progress, We Must Break Through the Cultural Barrier of Breach Disclosure Shame

Although we repeatedly hear that cyber adversaries have an upper hand due to the sharing and rapid dissemination of tools, techniques, and intelligence among like-minded attackers, the hard-earned lessons gained by defenders are tightly closeted — most often under a shroud of shame and reluctantly disclosed, if ever. For cyber-defense to progress, we must break through the cultural barrier of disclosure shame.

Despite most enterprises adopting an “assumed breach” approach to securing their business, the successes and investments that lead to uncovering breaches are too often thoroughly undermined by the perception of having failed to preemptively protect the environment.

Multiple longstanding movements aid the sharing of selective artifacts of an attack – most often those that were successfully thwarted or captured using generic blocking technologies. These artifacts (e.g. malware and phishing samples) and their associated telemetry (e.g. detonation logs) are useful from a threat intelligence perspective and are increasingly consumed with greater agility by both investigative and blocking protection systems, but they can’t communicate the important dimensions needed to help prevent the next novel threat or attack vector. Missing is the technical biopsy of the entire chain of events that resulted in a system compromise – in particular, what defensive or detection apparatus worked and what didn’t.

Security teams gain snippets of insight from defensive failures through public breach disclosures or the investigative reporting that follows large-scale and brand-name hacks. The stigma of past public disclosures causes most companies to go dark when a breach is detected and to resurface months later only after satisfying themselves that similar weaknesses have been internally dealt with – through technology or leadership change. That shroud of darkness is arguably a critical time in which disseminating details is the most valuable to other defenders around the globe.

In closed-door, invite-only forums, there is more willingness to share additional information about security failures – in more detail and in a timelier manner – but they are infrequent and highly localized. In fact, there are many parallels with how TV portrays an Alcoholics Anonymous meeting – e.g., “My name is Beth and I’ve been breached for 6 months …” – with an aura of shame, acknowledgement of past missteps, and hope for future well-being.

New scoring systems coming to market make it easier for organizations to both understand and monitor changes in their own enterprise security ecosystem. At the moment there are as many defense scoring systems as there are vendors that include them, but I believe that they’ll consolidate rapidly this year – most likely following the lead of the largest public cloud providers. It is exciting to meet with CISOs and other security leaders, openly comparing their scores and sharing tips on how they’re looking to improve them. I had not realized that gamification could be such a blessing to defenders.

Although defense scoring lowers the barrier to sharing defensive success insights, it does not yet address the insights gained from learning from others’ failures and the stigma of a breach.

Upon “going dark” after a breach detection, the security products vendors used within the compromised environment are similarly shut out – at precisely the time they can potentially add the most value to both the victim and the wider defensive ecosystem. It is in vendors’ best interest to leverage both their engineering and security research teams to promptly dissect and understand failures in their detection apparatus or missed capabilities in defending any chained or sequenced attack – and CISOs should leverage that deep expertise to complement their internal efforts as soon as they can.

With today’s complex and rapidly changing ecosystem of layered defenses, suite integrations, data connectors, automated response orchestration, policy configurations, and hybrid environments, breach response to a new threat or attack technique is rarely distilled down to adding a new detection signature or firewall rule. 

I thoroughly recommend a war room approach, with technical representatives from the vendors of the security products the organization deployed and had anticipated would directly or indirectly discover and protect against the overall threat. Those vendors should be charged with both optimizing existing product capabilities (that may have been misconfigured, new, or poorly understood) within the compromised environment and, if needed, the coordination and acceleration of engineered updates or feature capabilities to prevent any repeated and related attack. Leverage the R&D expertise of your security vendors – you’ve probably already paid for it!

It should not be a blame game (unless product inadequacies really are to blame!) – rather, the collective team should identify optimal routes to earlier detection and prevention, both short term and long term.

Bringing trusted vendors into the breach equation early on should accelerate a stable and robust threat response. 

The stigma of a breach can be shared with vendors and any associated public shame lessens with rapid threat response. The story of how a CISO and her vendors collectively and dynamically responded to a new threat, and how that knowledge was timely shared and incorporated into their products for all to benefit, is an incredibly strong one.

-- Gunter Ollmann

First Published: SecurityWeek - February 4, 2020

The Changing Face of Cloud Threat Intelligence

As public cloud providers continue to elevate their platforms’ default enterprise protection and compliance capabilities to close gaps in their portfolio or suites of in-house integrated security products, CISOs are increasingly looking to the use and integration of threat intelligence as the next differentiator within cloud security platforms.

Whether thinking in terms of proactive or retroactive security, the incorporation (and production) of timely and trusted threat intelligence has been a core tenant of information security strategy for multiple decades — and is finally undergoing its own transformation for the cloud.

What began as lists of shared intelligence covering infectious domains, phishing URLs, organized crime IP blocks, malware CRCs and site classifications, etc., has broadened and become much richer —  encompassing inputs such as streaming telemetry and trained detection classifiers, through to contributing communities of detection signatures and incident response playbooks. 

Cloud-native security suites from the major public cloud providers are striving to use threat intelligence in ways that have been elusive to traditional security product regimes. Although the cloud can, has and will continue to collect and make sense out of this growing sea of raw and semi-processed threat intelligence, newer advances lie in the progression and application of actionable intelligence. 

The elastic nature of public cloud obviously provides huge advancements in terms of handling “internet-scale” datasets — making short work of correlation between all the industry-standard intelligence feeds and lists as they are streamed. For example, identifying new phishing sites without any user being the first victim, by correlating streams of new domain name registrations (from domain registrars) with authoritative DNS queries (from global DNS providers), together with IP reputation lists, past link and malware detonation logs, and continuous search engine crawler logs, in near real time.

Although the cloud facilitates the speed in which correlation can be made and the degree of confidence placed in each intelligence nugget, differentiation lies in the ability to take action. CISOs have grown to expect the mechanics of enterprise security products to guarantee protection against known and previously reported threats. Going forward, those same CISOs anticipate cloud providers to differentiate their protection capabilities through their ability to turn “actionable” into “actioned” and, preferably, into “preemptively protected and remedied.”

Some of the more innovative ways in which “threat intelligence” is materializing and being transformed for cloud protection include:

• Fully integrated protection suites. In many ways the term “suite” has become archaic as the loose binding of vendor-branded and discrete threat-specific products has transformed into tightly coupled and interdependent protection engines that span the entire spectrum of both threats and user interaction — continually communicating and sharing metadata — to arrive at shared protection decisions through a collective intelligence platform.
• Conditional controls. Through an understanding of historical threat vectors, detailed attack sequencing and anomaly statistics, new cloud protection systems continually calculate the probability that an observed sequence of nonhostile user and machine interactions is potentially an attack and automatically direct actions across the protection platform to determine intent. As confidence of intent grows, the platform takes conditional and disruptive steps to thwart the attack without disrupting the ongoing workflow of the targeted user, application or system. 
• Step back from threat normalization. Almost all traditional protection technologies and security management and reporting tools require threat data to be highly structured through normalization (i.e., enforcing a data structure typically restricted to the most common labeled attributes). By dropping the harsh confines of threat data normalization, richer context and conclusions can be drawn from the data — enabling deep learning systems to identify and classify new threats within the environments they may watch over.
• Multidimensional reputations. Blacklists and whitelists may have been the original reputational sources for threat determination, but the newest systems not only determine the relative reputational score of any potential device or connection, they may also predict the nature and timing of threat potential in the near future — preemptively enabling time-sensitive switching of context and protection actions.
• Threat actor asset tracking. Correlating between hundreds or thousands of continually updated datasets and combined with years of historical insight, new systems allow security analysts to track the digital assets of known threat actors in near real time — labeling dangerous corners of the internet and preemptively disarming crime sites.

With the immense pressure to move from detection to protection and into the realm of preemptive response, threat intelligence is fast becoming a differentiator for cloud operators — but one that doesn’t naturally fit previous sharing models — as they become built-in capabilities of the cloud protection platforms themselves.

As the mechanics of threat protection continue to be commoditized, higher value is being placed on standards such as timeliness of response and economics of disruption. In a compute world where each action can be viewed and each compute cycle is billed in fractions of a cent, CISOs are increasingly cognizant of the value deep integration of threat intelligence can bring to cloud protection platforms and bottom-line operational budgets.

-- Gunter Ollmann

First Published: SecurityWeek - January 14, 2020

Harnessing Stunt Hacking for Enterprise Defense

Make Sure You Understand the Root Cause of the Vulnerabilities or Attack Vectors Behind the Next Over-Hyped Stunt Hack

Every year, at least one mediocre security vulnerability surprisingly snatches global media attention, causing CISOs and security researchers to scratch their heads and sigh “who cares?”

Following a trail of overly-hyped and publicized security bugs in smart ovens, household fridges, digital teddy bears, and even multi-function toilet-bidets, the last few weeks have seen digital SLR camera vulnerabilities join to the buzz list. Yet, this latest hack boils down to a set of simple WiFi enabled file-sharing flaws in a mid-priced camera that allowed researchers to demonstrate specially crafted ransomware attacks. It is not an obvious or imminent threat to most enterprise networks.

Love it or loathe it, stunt hacking and over-hyped bugs are part of modern information security landscape. While the vast majority of such bugs represent little threat to business in reality, they stir up legitimate questions. Does marketing security hacks to a fever-pitch cause more harm than good? Are stunts a distraction or amplifier for advancing enterprise security?

There is little doubt within the security researcher community that a well-staged vulnerability disclosure can quickly advance stalled conversations with reluctant vendors. Staged demonstrations and a flare for showmanship had the healthcare industry hopping as security flaws embedded in surgically implanted insulin pumps and heart defibrillators became overnight dinner-table discussions and murder plots in TV dramas. A couple years later, prime time news stories of researchers taking control of a reporter’s car – remotely steering the vehicle and disabling breaking – opened eyes worldwide to the threats underlying autonomous vehicles, helping to create new pillars of valued cyber security research.

Novel technologies and new devices draw security researchers like moths to a flame – and that tends to benefit the community as a whole. But it is often difficult for those charged with defending the enterprise to turn awareness into meaningful actions. A CFO who’s been sitting on a proposal for managed vulnerability scanning because the ROI arguments were a little flimsy may suddenly approve it on reading news of how the latest step-tracking watch inadvertently reveals the locations of secret military bases around the world.

In a world of over-hyped bugs, stunt hacking, and branded vulnerability disclosures, my advice to CISOs is to make security lemonade by finding practical next steps to take:

1. Look beyond the device and learn from the root cause of the security failing. Hidden under most of the past medical device hacks were fundamental security flaws involving outdated plain-text network protocols and passwords, unsigned patching and code execution, replay attacks and, perhaps most worrying, poorly thought through mechanisms to fix or patch devices in the field. The outdated and unauthenticated Picture Transfer Protocol (PTP) was the root cause of the SLR camera hack.
2. Use threat models to assess your enterprise resilience to recently disclosed vulnerabilities. The security research community waxes and wanes on attack vectors from recent bug disclosures, so it often pays to follow which areas of research are most in vogue. The root cause vulnerabilities of the most recent hacks serve as breadcrumbs for other researchers hunting for similar vulnerabilities in related products. For this reason, build threat models for all form factors the root flaw can affect.
3. Learn, but don’t obsess, over vulnerable device categories and practice appropriate responses. At the end of the day, a WiFi-enabled digital SLR camera is another unauthenticated removable data storage unit that can potentially attach to the corporate network. As such, the response should be similar to any other roaming exfiltration device. Apply the controls for preventing a visitor or employee roaming a datacenter with a USB key in hand to digital SLR cameras.

Regardless of how you feel about the showmanship of stunt hacking, take the time to understand and learn from their root causes. While it is highly unlikely that an attacker will attempt to infiltrate your organization with a digital SLR camera (there are far easier and more subtle hacking techniques that will achieve the same goal), it is still important to invest in appropriate policies and system controls to defend vulnerable vectors.

With more people seeking futures as security researchers, it would be reasonable to assume that more bugs (in a broader range of devices and formats) will be disclosed. What may originally present as a novel flaw in, let us say, a robotic lawnmower, may become the seed vector for uncovering and launching new 0-day exploits against smart power strips in the enterprise datacenter at a later date.

Chuckle or cringe, but make sure you understand the root cause of the vulnerabilities or attack vectors behind the next over-hyped stunt hack and don’t have similar weaknesses in your enterprise.

-- Gunter Ollmann

First Published: SecurityWeek - August 20, 2019

Digital Transformation Makes the Case for Log Retention in Cloud SIEMs

As organizations pursue their digital transformation dreams, they’ll migrate from on-premises SIEM to cloud-based SIEM. In the process of doing so, CISOs are taking a closer look at their previous security incident and event log retention policies, and revisiting past assumptions and processes.

For organizations needing to maintain a smorgasbord of industry compliance and regulatory requirements, overall event log retention will range from one year through to seven. Many organizations find that a minimum of one year meets most mandated requirements but err on the side of retaining between three to four years – depending on what their legal counsel advises.

With public cloud, data retention spans many different options, services, and price points. Backups, blob storage, “hot” access, “cold” access, etc. – there are endless ways to store and access security events and logs. With cloud storage dropping in price year-on-year, it’s cheap and easy to just store everything forever – assuming there’s no rush or requirement to inspect the stored data. But hot data, more expensive than the cold option, gives defenders the quick access they need for real-time threat hunting. Keeping data hot for SIEM use is inevitably one of the more expensive data storage options. A balance needs to be struck between having instant access to SIEM for queries and active threat hunting, and long-term regulatory-driven storage of event and log data. Can an optimal storage balance be achieved?

Widely available public threat reports for the last couple of years provide a “mean-time” to breach discovery ranging from 190 to 220 days and a breach containment window of between 60 to 100 days. Therefore, keeping 220 days of security event logs “hot” and available in a cloud SIEM would statistically only help with identifying half of an organization’s breaches. Obviously, a higher retention period makes sense – especially for organizations with less mature or less established security operations capabilities.

However, a sizable majority of SIEM-discoverable threats and correlated events are detectable in a much shorter timeframe – and rapidly detecting these breaches naturally makes it considerably more difficult for an adversary to maintain long-time persistence. For example, automatically piecing together the kill chain for an email phishing attack that led to a malware installation, that phoned home to a malicious C&C, which had then brute-forced the administrative access to a high value server is almost trivial for cloud SIEM (assuming appropriate logging was enabled). Nowadays, such a scenario (or permutation of that scenario) likely accounts for near half of all enterprise network breaches.

My advice to organizations new to cloud SIEM is to begin with a rolling window of one year’s worth of event logs while measuring both the frequency of breaches and time to mitigate. All older event logs can be stored using cheaper cloud storage options and needn’t be immediately available for threat hunting.

Depending on the security operations teams’ capacity for mitigating the events raised by cloud SIEM, it may be financially beneficial to reduce the rolling window if the team is overwhelmed with unresolvable events. I’d be hesitant to reduce that rolling window. Instead, I would recommend CISOs with under-resourced teams find and engage a managed security services provider to fill that skills gap.

A question then arises as to the value of retaining multiple years of event logs. Is multi-year log retainment purely a compliance tick-box?

While day-to-day cloud SIEM operations may focus on a one-year rolling window, it can be beneficial to organize a twice-annual threat hunt against several years of event logs using the latest available threat intelligence and indicator of compromise (IoC) information as seeds for investigation. These periodic events have two objectives: reduce your average monthly cloud SIEM operating costs (by temporarily loading and unloading the historic data) and allow teams to change mode and “deep dive” into a broader set of data while looking for “low and slow” compromises. If an older breach is detected, incrementally older event logs could be included in the quest to uncover the origin point of an intruder’s penetration or full spectrum of records accessed.

Caution over infinite event log retention may be warranted, however. If the breached organization only has a couple years of logs, versus being able to trace breach inception to, say, four years earlier, their public disclosure to customers may sound worse to some ears (including regulators). For example, disclosing “we can confirm customers over the last two years are affected” is a weaker disclosure than “customers since July 4th 2015 are affected”. Finding the sweet-spot in log retention needs to be a board-level decision.

Having moved to cloud SIEM, CISOs also need to decide what logs should be included and what log settings should be used.

Ideally, all event logs should be passed to the cloud SIEM. That is because the AI and log analytics systems powering threat detection and automated response thrive on data. Additionally, inclusion of logs from the broadest spectrum of enterprise devices and applications will help reduce detection times and remove potential false positives, which increase overall confidence in the system’s recommendations.

Most applications and networked appliances allow for different levels of logging, including scaling from error messages to alerts and error messages through to errors, warnings, status messages, and debugging information. In general, the greater the detail in the event logs, the greater the value they bring to cloud SIEM. In this way, upgrading from “normal” to “verbose” log settings can offer several threat response advantages – particularly when it comes to handling misconfigurations and criticality determination.

The symbiotic development of cloud SIEM and cloud AI innovation continues at an astounding pace. While cloud SIEM may be new for most organizations, its ability to harness the innate capabilities of public cloud are transforming security operations. Not only are threats being uncovered quicker and responses managed more efficiently, but continual advancements in the core AI makes the technology more valuable while costs of operating SIEM and storing data in the cloud continue to drop. This makes it possible for companies to make pragmatic use of the intelligent cloud by operating on a one-year window of hot data while getting value out of older data, stored cold, on twice a year threat hunts.

-- Gunter Ollmann

First Published: SecurityWeek - July 22, 2019

Hacker History I: Getting Started as a Hacker

Curiosity is a wonderful thing; and the key ingredient to making a hacker. All the best hackers I know are not only deeply curious creatures but have a driving desire to share the knowledge they uncover. That curiosity and sharing underpins much of the hacker culture today – and is pretty core to people like me and those I trust the most.

Today I continue to get a kick out of mentoring other hackers, (crossed-fingers) upcoming InfoSec stars and, in a slightly different format, providing “virtual CISO” support to a handful of professionals (through my Ablative Security company) that have been thrown headfirst into protecting large enterprise or local government networks.

One of the first questions I get asked as I’m mentoring, virtual CISO’ing, or grabbing beers with a new batch of hacker friends at some conference or other is “how did you get started in computers and hacking?”.

Where did it all start?

The early days of home computing were a mixed bag for me in New Zealand. Before ever having my own computer, a bunch of friends and I would ditch our BMX’s daily in the front yard of any friend that had a Commodore VIC20 or Amstrad CPC, throw a tape in the tape reader, and within 15 minutes be engrossed in a game – battling each other for the highest score. School days were often dominated by room full of BBC Micros – where one of the most memorable early programs I wrote was to use a sensitive microphone to capture the sounds of bugs eating. I can still remember plotting the dying scream of a stick insect as it succumbed to science!

Image via: WorthPoint

I remember well the first computer I actually owned – a brand-spanking new SpectraVideo SV-328 (complete with cassette tape reader) that Santa delivered for Christmas in 1983. I thought it was great, but quickly tired of it because there weren’t many games and all my friends were getting Commodore VIC-20 or Commodore 64 microcomputers – which had oh so many more games. So, come late 1984, I flogged my SpectraVideo and brought (second-hand) my first Commodore 64 (C64).

I can safely say that it was the C64 that lit my inner hacker spark. First off, the C64 had both a tape (then later diskette) capability and a games cartridge port. Secondly, New Zealand is a LONG way from where all the new games were being written and distributed from. Thirdly, as a (pre)teen, a single cartridge game represented 3+ months of pocket money and daily newspaper deliveries.

These three constraints resulted in the following:

• My first hardware hack. It was possible to solder a few wires and short-circuit the memory flushing and reboot process of the C64 via the games cartridge mechanism to construct a “reset” button. This meant that you could insert the game cartridge, load the game, hold-down your cobbled together reset button, remove the games cartridge, and use some C64 assembly language to manipulate the game (still in memory). From there you could add your own boot loader, save to tape or floppy, and create a back-up copy of the game.
• “Back-up Copies” and Community. C64 games, while plentiful, were damned expensive and took a long time to get to New Zealand. So a bunch of friends all with C64’s would pool our money every few weeks to buy the latest game from the UK or US; thereafter creating “back-ups” for each-other to hold on to – just in case the costly original ever broke. Obviously, those back-up copies needed to be regularly tested for integrity.  Anyhow, that was the basis of South Auckland’s community of C64 Hackers back in 1983-1985. A bunch of 10-14 year-olds sharing the latest C64 games.
• Copy-protection Bypassing. Unsurprisingly, our bunch of kiwi hackers weren’t the first or only people to create unauthorized back-ups of games. As floppies replaced tapes and physical cassettes as the preferred media for C64 games, the software vendors started their never-ending quest of adding copy-protection to protect unauthorized copying and back-ups. For me, this was when hacking become a passion. Here were companies of dozens, if not hundreds, of professional software developers trying to prevent us from backing-up the programs we had purchased. For years we learned, developed, and shared techniques to bypass the protections; creating new tools for backing-up, outright removal of onerous copy-protection, and shrinking bloated games to fit on single floppies.
• Games Hacking. At some point, you literally have too many games and the thrill of the chase changes. Instead of looking forward to playing the latest game for dozens of hours or days and iteratively working through campaigns, I found myself turning to hacking the games themselves. The challenge became partially reversing each game, constructing new cheats and bypasses, and wrapping them up in a cool loader for a backed-up copy of the game. Here you could gain infinite lives, ammo, gold, or whatever, and quickly step through the game – seeing all it had to offer and doing so within an hour.
• Hacking for Profit. Once some degree of reputation for bypassing copy-protection and creating reliable cheater apps got around, I found that my base of “friends” grew, and monetary transactions started to become more common. Like-minded souls wanted to buy hacks and tools to back-up their latest game, and others wanted to bypass difficult game levels or creatures. So, for $5-10 I’d sell the latest cheat I had.

At some point in 1986 I recognized that I had a bunch of C64 equipment – multiple floppy drives, a few modems, even a new Commodore 64C – and more than enough to start a BBS.

This is PART ONE of THREE. 

PART TWO (BBS Hacking) is up and PART THREE (Radar Hacking) on Wednesday.