The Symbiosis Between Public Cloud and MSSPs

To the surprise of many, public cloud appears to be driving a renaissance in adoption and advancement of managed security service providers (MSSP).

For several years, the major public cloud providers have settled upon a regular rhythm of rolling out new security features for inclusion in their workload management tooling – adding new detections and alerting capabilities that, for want of a better description, are designed to help subscribers clean up an expanding corpus of horrible little mistakes that expose confidential information or make it easy for an attacker to abuse valuable resources and steal intellectual property. To my mind, this incremental rollout of embedded security features represents perhaps the single most valuable advantage of moving to the cloud.

Many of these security features are simple and non-intrusive. For example, they could alert the subscriber that they just created a publicly accessible data storage device that is using a poor administrator password, or that they’re about to spin up a virtual machine (VM) that hasn’t been patched or updated in nine months. Moving beyond alerts, the cloud security tooling could also propose (or force – if enforcing compliance mandate) that both a stronger password be used and that multi-factor authentication be applied by clicking a button or, in the case of a dated VM, auto-patch the OS and installing an updated security suite on the image. 

Getting these security basics done right and applied consistently across millions of subscribers and tens of millions of workloads has, year over year, proved that businesses operating in the public cloud are more secure than those that are solely on-premises. Combining the cloud’s security benefits with MSSP solutions unlocks even greater value, the most common of which are:

Small and medium businesses (SMB), prior to moving to the cloud, were lucky to have a couple of IT support staff who probably between them managed three or four security technologies (e.g. anti-virus, firewall, VPN, and an anti-phishing gateway). Upon moving to the cloud, the IT team are presented with 20+ default running security services and another 50+ security product options available within a single clicks reach, and are simply overwhelmed by the volume of technology presented to them and the responsibility of managing such a diverse portfolio of security products.

The move to the cloud is not the flick of a switch, but a journey. The company’s in-house security team must continue to support the legacy on-premises security technology while learning and mastering an even larger set of cloud-based security options and technologies. These teams are stretched too thin and cannot afford the time to “retrain” for the cloud.

Businesses embracing DevOps strive to optimize value and increase the pace of innovation in the cloud. Operationalizing a DevOps culture typically requires the business to re-orient their internal security team and have them master SecDevOps. As in-house security expertise focuses on SecDevOps, daily security operational tasks and incident response require additional resourcing.

Locating, hiring, and retaining security talent is becoming more difficult – especially for SMBs. Companies moving to the cloud typically either hire new security expertise to carry the organization into the cloud or retrain their smartest and most valuable in-house security talent to try to backfill those “legacy” security roles.

Traditionally, MSSPs value lay in their ability to manage a portfolio of security products that they sold to and installed into their customers’ environments. To ensure service level quality and depth of knowledge, the most successful MSSPs would be highly selective and optimize the portfolio of security products they could support.

As their customers move workloads to the public cloud, larger MSSPs are retraining their technical teams in the cloud-native security offerings from the top public cloud providers. In tandem, the MSSPs are updating their internally developed SOC, NOC, and incident handling tools to embrace the default public cloud provider’s APIs and security products. 

At the same time, MSSPs, appear to be doing better with hiring and retaining security expertise than SMBs. Not only are they able to pay higher salaries but, perhaps more importantly, they’re able to provide the career development paths not present in smaller businesses through a diverse spectrum of security challenges spread over multiple customer environments. 

The parallel growth of default public cloud security capabilities and MSSP adoption offers a solution for the dearth of entry level information security personnel and access to experienced incident responders. Combining cloud efficiencies with MSSP delivery creates advanced capabilities beyond that on-premises only defense can achieve.

Smart MSSPs are embracing cloud operations for their own optimizations and service delivery. Many are taking advantage of the built-in AI and elastic compute capabilities to provide more advanced and personalized security services to customers – without needing to scale their pool of human experts. In this way businesses embracing the efficiencies of the public cloud and on-demand security expertise gain a critical advantage in working around the shortage of security professionals.

Today we have less horses from a century ago and consequently less trained farriers but more qualified welders. As businesses move to the cloud and embrace MSSP, this will make it possible to deliver advanced capabilities that help fill entry level security requirements which account for the majority of security vacancies around the world. As result, existing defenders can work on higher level problems, enabling companies to cover more ground.

-- Gunter Ollmann

First Published: SecurityWeek - June 11, 2019

From APES to Bespoke Security Automated as a Service

Many of the most innovative security start-ups I come across share a common heritage – their core product evolved from a need to automate the delivery of an advanced service that had begun as a boutique or specialized consulting offering. Start-ups with this legacy tend to have bypassed the “feature looking for a problem” phase that many others struggle with and often launch their products on day-one alongside a parade of satisfied marque accounts.

While there isn’t a universal formula for success, over my years delivering boutique professional security services, I have been very lucky to encounter that product evolution several times, usually resulting from consultants intelligently automating the repetitive parts of their jobs away and creating a new class of product.

For example, around the turn of the millennium, when penetration testing came to the fore as the cutting edge in security consulting, the need for automating away the drudgery of port scans and vulnerability scanning was obvious. The first foray led to tooling that freed up consultants to focus on the “art” of bug hunting and recognition that some customers needs were satisfied with those basic capabilities. During my time at Internet Security Systems, that first automation came to be known as the “monkey scan” – because of how easy it was to run. Of course, once the marketing team got wind of customers purchasing the scanning service, a more sensible name was needed and so Automated Perimeter and Enterprise Scanner (APES) was born. From humble beginnings, that X-Force managed service line business grew and, through acquisition, its legacy continues today as part of IBM’s Managed Security Services Provider (MSSP) business. 

Automation of repetitive consulting tasks is an obvious and critical element, but so too is the need to ensure consistency and exhaustive completion of delivery. Along my own journey I’ve seen former colleagues spawn companies such as SPI Dynamics and PortSwigger Web Security (i.e. Burp Proxy) to bring to market new web application security testing tools, Continuum Security SL to solve SDLC-based threat modelling and risk management challenges, Endgame to kickstart the nation-state threat intelligence market, and AttackIQ to construct and define the Attack and Breach Simulation category – all springing from the imagination of talented consultants looking to make life just a little bit easier.

To understand what the next innovative security technology will be, we should look closely at the premium service offerings from specialized services boutique consulting companies and pay attention to those services that have a documented and repeatable methodology. While many young specialist service lines may present themselves as more “art” than “science” – the turning point comes with the development and enforcement of a standardized methodology.

A service methodology ensures consistency of delivery. Consistency means that the differentiated elements of the service can be, or must be, repeatable. If they are repeatable, then they almost always can be automated. If key elements of the service are automatable, then they can be productized. 

The depth of service that automation can deliver roughly defines whether the product will be most effectively delivered as a managed security service, a self-service SaaS offering, or a stand-alone product.

In the past, that evolution from boutique consulting service to top-right corner market leading product has taken a few years – typically three years for productization and market awareness, then another three to five before analysts label and assign a market segment. I anticipate that more consulting services will mature into products and the overall pace will increase over coming years because public cloud and AI are rapidly accelerating the gestation of these products. 

Just as many of the most innovative companies launch as cloud-native, security consultants have similarly embraced and applied their expertise in cloud environments. Consultants were often constraint bound by their clients’ hardware and physical locations. Now, when consultants need to automate repetitive tasks (e.g. enumerating APIs, fuzzing payloads, etc.) or to test a hypothesis, they already have the tools in front of them – with no energy lost in applying them. This greatly shortens the time needed to prototype new cross-client solution sets and capabilities.

But automation will only go so far. A successful product needs to capture and distill the expertise and experience that a specialist consultant applies when interpreting the output of all those automated tasks. This is where advances in AI are accelerating the product creation process and transforming managed services businesses.

Off-the-shelf AI libraries and cloud services are allowing innovators to move from linear content creation modes (e.g., each threat requires a unique signature) and decades-old if-then-else logic to training classifier systems capable of identifying and labeling swathes of the problem space they are seeking to solve, and teaching systems to learn new responses directly from the actions the consultants  are already undertaking to solve their customers’ problems.

In my time as a CISO for organizations that often required security consulting expertise, I’ve engaged in reviewing the methodology that consultants will be applying to my systems. Lack of a detailed methodology will inevitably lead to inconsistent results and lack of repeatability, the death knell of compliance. When reviewing a proposed methodology, a CISO should also ask about the automation process framework and whether those automated tasks can be separated from consultant billing. This could possibly reduce overall job costs, but also prompts your consulting partners to accelerate an important services transition into a more versatile product.

For my former consulting brethren, take a critical look at the innovative services you are delivering. Stop playing the “art” card and instead focus on the detailed methodology that’ll promote repeatability and confidence in your service. From there, invest time in applying the resources of public cloud to bring automation, scalability, and AI to solving the given problem as a platform for all customers – past, present, and future.

-- Gunter Ollmann

First Published: SecurityWeek - May 21, 2019

To Reach SIEM’s Promise, Take a Lesson From World War II

With two of the largest public cloud providers having launched their cloud Security Information and Event Management (SIEM) products and an inevitability that the remainder of the top 5 cloud providers will launch their own permutations some time this year, 2019 is clearly the year of the cloud SIEM.

For an on-premises technology that has been cursed with a couple decades of over-promising, under-achieving, and eye-watering cost escalation, modernizing SIEM into a cloud native security technology is a watershed moment for the InfoSec community.

The promise of finally being able to analyze all the logs, intelligence, and security data of an enterprise in real-time opens the door to many great and obvious things. We can let the SIEM vendors shout about all the obvious defensive value cloud SIEM brings. Instead, I’d like to focus on a less obvious but arguably more valuable long-term contribution that a fully capable cloud SIEM brings to enterprise defense.

Assuming an enterprise invests in bringing all their network logs, system events, flow telemetry, and security events and alerts together into the SIEM, businesses will finally be able to track threats as they propagate in an environment. Most importantly, they’ll be able to easily identify and map the “hotspots” of penetration and compromise, and remedy accordingly.

A unified view will also allow analysts and security professionals to pinpoint the spots where compromises remain hidden from peering eyes. As enterprises strive to deploy and manage an arsenal of threat detection, configuration management, and incident response tools in increasingly dynamic environments, visibility and coverage wax and wane with each employee addition, wireless router hook-up, application installation, or SaaS business connection. Those gaps, whether temporary or permanent, tend to attract an unfair share of compromise and harm.

In World War II, a gentleman by the name of Abraham Wald was a member of Columbia University’s Statistical Research Group (SRG). One problem SRG was tasked with was examining the distribution of damage to returning aircraft and advise on how to minimize bomber losses to enemy fire. A premise of the research was that the areas of bombers that were most damaged and therefore susceptible to flak should be redesigned and made more robust. Wald noted that such a study was biased to only aircrafts that survived their missions and, if you were to assume that damage was more uniformly distributed to all aircrafts, those that returned had actually been hit in the less vulnerable parts. By mapping the damage done to the surviving aircraft, the “undamaged” areas represented the most vulnerable parts of the aircrafts that didn’t survive to return.

Wald’s revelations and work were seminal in the early days of Operational Research – a discipline of applying advanced analytical methods to help make better decisions. I expect cloud SIEM and the integration of AI systems to usher Operational Research and its associated disciplines into the information security sector. Securing an enterprise is a highly complex and dynamic problem and, because Operational Research is focused on optimizing solutions for complex decision-making problems, it is well suited to finding solutions that balance the multi-faceted aspects of business continuity and risk.

As we’re in the early days for cloud SIEM, I’ve yet to see much in the area of employing native AI to address the cold-spots in enterprise threat visibility. The focus to-date is applying AI in threat hunting and automating the reconstruction of kill chain associated with an in-progress attack and supplementing that visualization with related threat intelligence and historical data artifacts.

Putting on a forecasting hat, I expect much of the immediate adoption and growth of cloud SIEM will be driven by desire to realize the promises of on-premises SIEM, in particular, using supervised-learning systems to automate the detection and mitigation of the threats that have pestered security operations teams for twenty-plus years. Infusing SIEM natively on the cloud provider’s platform also creates end to end visibility into security related events inside a business’ environment and pieces in valuable intelligence from the cloud provider’s operations – thereby harnessing the “cloud effects” of collective intelligence and removing the classic requirement for a “patient zero” to initiate an informed response.

What I hope is, once engineering teams have matured those hunting and mitigation capabilities by weaving in AI decision systems and real-time data processing, the “science” of information security can finally come up for air and move forward.

Leveraging the inherent power and scale of public cloud for real-time analytics of enterprise security data at streaming rates means that we’re at the cusp of finally calculating the ROI of each security technology deployed inside an enterprise. That alone should have many CISOs and CFOs jumping for joy. With all the enterprise security data flowing to one place, the cloud SIEM also becomes the anchor for IT operations – such as tracking the “meantime between failures” (MTBF) of protected systems, providing robustness metrics for software assets and system updates, and surfacing the latent risks of the environments being monitored.

75 years may separate War World II from cloud SIEM, but we’re on the cusp of being able to apply the hard-earned learnings from Abraham Wald in our latest adversarial conflict – the cyberwar.

-- Gunter Ollmann

First Published: SecurityWeek - April 30, 2019

Get Ready for the First Wave of AI Malware

While viruses and malware have stubbornly stayed as a top-10 “things I lose sleep over as a CISO,” the overall threat has been steadily declining for a decade. Unfortunately, WannaCry, NotPetya, and an entourage of related self-propagating ransomware abruptly propelled malware back up the list and highlighted the risks brought by modern inter-networked business systems and the explosive growth of unmanaged devices.

The damage wrought by these autonomous (not yet AI-powered) threats should compel CISOs to contemplate the defenses to counter such a sophisticated adversary.

The threat of a HAL-9000 intelligence directing malware from afar is still the realm of fiction, so too is the prospect of an uber elite hacker collective that has been digitized and shrunken down to an email-sized AI package filled with evil and rage. However, over the next two to three years, I see six economically viable and “low hanging fruit” uses for AI infused malware – all focused on optimizing efficiency in harvesting valuable data, targeting specific users, and bypassing detection technologies.

• Removing the reliance upon frequent C&C communications – Smart automation and basic logic processing could be employed to automatically navigate a compromised network, undertake non-repetitive and selective exploitation of desired target types and, upon identification and collection of desired data types, perform a one-off data push to a remote service controlled by the malware owner. While not terribly magical, such AI-powered capabilities would not only undermine all perimeter blacklist and enforcement technologies, but also sandboxing and behavioral analysis detection.
• Use of data labeling and classification capabilities to dynamically identify and capture the most interesting or valuable data –  Organizations use these types of data classifiers and machine learning (ML) to label and protect valuable data assets. But attackers can exploit the same search efficiencies to find the most valuable business data being touched by real users and systems and to reduce the size of data files for stealthy exfiltration. This enables attackers to sidestep traffic anomaly detection technologies as well as common deception and honeypot solutions.
• Use of cognitive and conversational AI to monitor local host email and chat traffic and to dynamically impersonate the user – The malware’s AI could insert new conversational content into email threads and ongoing chats with the objective of socially engineering other employees into disclosing secrets or prompting them to access malicious content. Since most email and chat security solutions focus on in-bound and egress content, internal communication inspection is rare. Additionally, conversational AI is advancing quickly enough to make socially engineering IT helpdesk and support staff into disclosing secrets or making temporary configuration a high probability.
• Use of speech to text translation AI to capture user and work environment secrets –Through a physical microphone, the AI component could convert all discussions within range of the compromised device to text. In addition, some environments may enable the AI to successfully capture the keystrokes of nearby systems and deduce what keys are being pressed. Such an approach also allows hackers to be more selective of what secrets to capture, further minimizing the volume of data that must be egressed from the business, which then reduces the odds of triggering network-based detection technologies.
• Use embedded cognitive AI in applications to selectively trigger malicious payloads – Since it is possible for cognitive AI systems to not only recognize a specific face or voice, but also determine their race, sex, and age, it is therefore possible for a malware author to be very specific in who they choose to target. Such malware may only be malicious for the CFO of the company or may only manifest itself if the interactive user is a pre-teen female. Because the trigger mechanism is embedded within complex AI, it becomes almost impossible for automated or manual investigation processes to determine the criteria for initiating the malicious behaviors.
• Capture the behavioral characteristics and traits of system users – AI learning systems could observe the unique cadence, timbre, and characteristics of the users typing, mouse movements, vocabulary, misspellings, etc. and create a portable “bio-profile” of the user. Such “bio-profiles” could then be reused by attackers to bypass the current generation of advanced behavioral monitoring systems that are increasingly deployed in high security zones.

These AI capabilities are commercially available today. Collectively or singularly, each AI capability can be embedded as code within malicious payloads.

Because deep neural networks, cognitive AI, and trained machine language classifiers are incredibly complex to decipher, the trigger mechanism for malicious behaviors may be deeply buried and impossible to uncover through reverse engineering practices.

The baseline for defending against these attacks will lie in ensuring all parts of the organization are visible and continually monitored. In addition, CISOs need to invest in tooling that brings speed and automation to threat discovery through AI-powered detection and response.

As malware writers harness AI for cybercrime, the security industry must push forward with a new generation of dissection and detonation technologies to prepare for this coming wave. A couple promising areas for implementing defensive AI include threat intelligence mining and autonomous response (more on this later).

-- Gunter Ollmann

First published: SecurityWeek - April 9, 2019

Hacker History III: Professional Hardware Hacker

Following on from my C64 hacking days, but in parallel to my BBS Hacking, this final part looks at my early hardware hacking and creation of a new class of meteorological research radar...

Ever since that first C64 and through the x86 years, I’d been hacking away – mostly software; initially bypassing copy-protection, then game cracks and cheats, followed by security bypasses and basic exploit development.

Before bug bounty programs were invented in the 2010’s, as early as 1998 I used to say the best way to learn and practice hacking skills was to target porn sites. The “theory” being that they were constantly under attack, tended to have the best security (yes, even better than the banks) and, if you were ever caught, the probability of ever appearing in court and having to defend your actions in front of a jury was never going to happen - and the folks that ran and built the sites would be the first to tell you that.

In the mid-to-late 1980’s, following France’s 1985 bombing and sinking of the Rainbow Warrior in New Zealand, if you wanted to learn to hack and not worry about repercussions – any system related to the French Government was within scope. It was in that period that war-dialing and exploit development really took off and, in my opinion, the professional hacker was born – at least in New Zealand it was. Through 1989-1991 I had the opportunity to apply those acquired skills in meaningful ways – but those tales are best not ever written down.

Digital Radar

Easily the most fun hardware hacking I’ve ever done or been involved with ended up being the basis for my post-graduate research and thesis. My mixed hardware hacking and industrial control experience set me up for an extraordinary project as part of my post graduate research and eventual Masters in Atmospheric Physics.

I was extremely lucky:

1. The first Mhz digitizer cards were only just hitting the market
2. PC buses finally had enough speed to handle Mhz digitizer cards
3. Mass storage devices (i.e. hard drives) were finally reaching an affordable capacity/price
4. My supervisor was the Dean of Physics and had oversight of all departments “unused budgets”
5. Digital radar had yet to be built

My initial mission was to build the world’s first digital high-resolution vertically pointing radar and to use it to prove or disprove the “Seeder-feeder mechanism of orographic rainfall”.

Taking a commercial analogue X-band marine radar and converting the 25 kilo-watt radar with a range of 50 miles and a resolution measured in tens-of meters, to a digital radar with an over-sampled resolution of 3.25 cm out to a range of 10km was the start of the challenge – but successfully delivered nevertheless. That first radar was mounted on the back of a 4x4 Toyota truck – which was great at getting to places no radar had been before. Pointing straight up was interesting – and served its purpose of capturing the Seeder-feeder mechanism in operation – but there was room for improvement.

Back at the (family) factory, flicking through pages of operation specification tables for electric motors (remember – pre-Internet/pre-Google) and harnessing the power of MS-DOS based AutoCAD, I spec'ed out and designed a mounting mechanism for making the radar scan the sky like a traditional meteorological radar – but one that could operate in winds of 80 mph winds, at high altitude, in the rain. Taking a leaf out of my father’s design book – it was massively over engineered ;-)

Home for many months - the mobile high resolution radar + attached caravan. Circa 1994.

This second radar was mounted to an old tow-able camper-van. It was funny because, while the radar would survive 80+ mph winds, a gust of 50+ mph would have simply blown over the camper-van (and probably down the side of a hill or over a cliff). Anyhow, that arrangement (and the hacks it took to get working) resulted in a few interesting scientific advances:

• Tracking bumblebees. Back in 1994, while GPS was a thing, it didn’t have very good coverage in the southern hemisphere and, due to US military control, it’s positioning resolution was very poor (due to Selective Availability). So, in order to work out a precise longitude and latitude of the radar system, it was back to ancient ways and tracking the sun. I had code that ran the radar in passive mode, scanned horizontally and vertically until it found that big microwave in the sky, and tracked its movements – and from there determine the radar’s physical location. (Un)fortunately, through a mistake in my programming and leaving the radar emitting it's 25kW load, I found it could sometimes lock-on and track bright blips near ground-level. Through some investigation and poor coding, I’d managed to build a radar tracking system for bumblebees (since bumblebees were proportional to the wavelength and over-sampled bin size – they were highly reflective and dominated the sun).
• Weather inside valleys. The portability of the camper-van and the high resolution of the radar also meant that for the first time ever it was possible to monitor and scientifically measure the weather phenomenon within complex mountain valley systems. Old long-range radar, with resolutions measured in thousands of cubic meters per pixel, had only observed weather events above the mountains. Now it was possible to digitally observe weather events below that, inside valleys and between mountains, at bumblebee resolution.
• Digital contrails. Another side-effect of the high resolution digital radar was its ability to measure water density of clouds even on sunny days. Sometimes those clouds were condensation trails from aircraft. So, with a little code modification, it became possible to identify contrails and follow their trails back to their root source in the sky – often a highly reflective aircraft – opening up new research paths into tracking stealth aircraft and cruise missiles.

It was a fascinating scientific and hacking experience. If you’ve ever stood in a doorway during a heavy rainfall event and watched a curtain of heavier rainfall weave its way slowly down the road and wondered at the physics and meteorology behind it, here was a system that digitally captured that event from a few meters above the ground, past the clouds, through the melting layer, and up to 10 km in the air – and helped reset and calibrate the mathematical models still used today for weather forecasting and global climate modeling.

By the end of 1994 it was time to wrap up my thesis, leave New Zealand, head off on my Great OE, and look for full-time employment in some kind of professional capacity.

A (much) later version of the High Resolution X-Band Radar.

When I look back at what led me to a career in Information Security, the 1980's hacking of protected C64 games, the pre-Internet evolution of BBS and it's culture of build collaboration, and the hardware hacking and construction of a technology that was game changing (for it's day) - they're the three things (and time periods) that remind me of how I grew the skills and developed the experience to tackle any number of subsequent Internet security problems - i.e. hack my way through them. I think of it as a unique mix. When I meet other hackers who's passions likewise began in the 1980's or early 1990's, it's clear that everyone has their own equally exciting and unique journey - which makes it all the more interesting.

I hope the tale of my journey inspires you to tell your own story and, for those much newer to the scene, proves that us older hands probably didn't really have a plan on how we got to where we are either :-)

This is PART THREE of THREE.

PART ONE (C64 Hacking)  and PART TWO (BBS Hacking) are available to read too.

--Gunter

Hacker History II: The BBS Years

Post-C64 Hacking (in Part 1 of Hacker History)... now on to Part 2: The BBS Years

Late 1986 (a few months before I started my first non-newspaper delivery and non-family-business job – working at a local supermarket) I launched my first bulletin board system (BBS). I can’t remember the software that I was running at the time, but it had a single 14k dial-up facility running on all the extra C64 equipment I’d been “gifted” by friends wanting faster/always access too my latest cheats and hacks.

The premise behind the BBS was two-fold: I wanted to learn something new (and hacking together a workable and reliable BBS system in the mid-80’s was a difficult enough challenge), and I saw it as a saving time distribution channel for my cheats/hacks; others could dial-in and download themselves, instead of me messing around with stacks of floppy discs etc.

At some point in 1986 I’d also saved enough money to by an IBM PC AT clone – a whopping 12Mhz 80286 PC, complete with Turbo button and a 10Mb hard drive. I remember specking out the PC with the manufacturer. They were stunned that a kid could afford their own PC AT and that he planned to keep it in his bedroom, and that he wanted an astounding 16k of video memory (“what do you need that for? Advanced ACAD?”)!

By 1989 the BBS had grown fairly large with a couple hundred regular members with several paying monthly subscription fees, but the stack of C64’s powering the BBS were showing their age and, in the meantime my main computing had moved down the PC path from 286, to 386, and to a brand-spanking new 486.

It was time to move on from C64 and go full-PC – both with the BBS and the hacks/cheats I was writing.

So in 1990, over the Summer/Christmas break from University I set about shifting the BBS over to a (single) PC – running Remote Access, with multiple dial-in lines (14.4k for regular users and 28.8k for subscribers).

The dropping of C64 and move to fully-fledged x86 PC resulted in a few memorable times for me:

• BBS’s are like pets. Owning and operating a BBS is a lot like looking after an oversized pet that eats everything in its path and has destructive leanings; they’re expensive and something is always going wrong. From the mid-80’s to mid-90’s (pre-“Internet”) having a BBS go down would be maddening to all subscribers. Those subscribers would be great friends when things were running, or act like ungrateful modern-day teenagers being denied “screen-time” if they couldn’t dial-in for more than a couple of days. Keeping a BBS running meant constant tinkering under the covers – learning the intricacies of PC hardware architecture, x86 assembly, live patching, memory management, downtime management, backup/recovery, and “customer management”. The heady “good-old days” of PC development.
• International Connectivity. With me in University and too-often referred to as the “student that knows more about computers than the campus IT team”, in 1991 I added Fidonet and Usenet support to my BBS. There had been a few BBS’s in New Zealand before mine to offer these newsgroups, but they were very limited (i.e. a small number of groups) because they were reliant upon  US dial-up for synching (which was damned expensive!). My solution was to use a spare modem in the pack of a University lab PC to connect semi-permanently to my BBS. From there my BBS used the Universities “Internet” undersea cable connectivity to download and synch all the newsgroups. Technically I guess you could call it my first “backdoor” hacking experience – which ended circa 1993 after being told to stop as (by some accounts) the BBS was peak consuming 1/3 of the entire countries academic bandwidth.
• First Security Disclosure. Setting up Remote Access (RA) was an ordeal. It was only a week later – Christmas Eve 1990 – that I publicly disclosed my first security vulnerability (with a self-developed patch); an authentication bypass to the system that controlled what games or zones a subscriber could access. I can’t remember how many bugs and vulnerabilities I found in RA, QEMM, MS-DOS, modem drivers, memory managers, and the games that ran on RA over those years. Most required some kind of assembly instruction patch to fix.
• Mailman and Sysop. Ever since those first BBS days in 1986, I’d felt that email (or Email, or E-Mail) would be the future for communications. The tools and skills needing for managing a reliable person-to-person or person-to-group communication system had to be built and learned – as too did the management of trust and the application of security. Some BBS operators loved being Sysops (System Operators – i.e. Admins) because they could indulge their voyeurism tendencies. I hated BBS’s and Sysops that operated that way and it became an early mission of mine to figure out ways of better protecting subscriber messages.

That fumbling about and experimenting with PC hardware, MS-DOS, and Windows at home and with the Bulletin Board System, coupled with learning new systems at University such as DEC Alpha, OpenVMS, Cray OS, and HP-UX in the course of my studies, and the things I had to piece-together and program at my parents factories (e.g. PLC’s,  ICS’s, RTU’s, etc.) all combined to add to a unique perspective on operating systems and hardware hacking.

By the time I’d finished and submitted my post-grad research thesis, it was time to tear down the BBS, sell all my computers and peripherals, and leave New Zealand for my Great OE (Overseas Experience) at the end of 1994.

This is PART TWO of THREE.

PART ONE (C64 Hacking) was posted yesterday and PART THREE (Radar Hacking) will be on Wednesday.

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.

Ubiquitous Video Surveillance and the Policing Paradigm Change it Brings

Policing in the 21st Century is obviously changing rapidly. New technological advances are fundamentally changing the way in which police forces and related government entities can track, locate, and collect evidence.

Two game changing technologies - working together - perhaps underpin the greatest tool for policing the world over. The combination of high-resolution digital video capture and facial recognition. Both sit at the crux of future policing and bring new societal change.

Projecting forward, what could the next decade or two hold? 

It's easy to get in to the realm of Science Fiction and dystopian futures, but when I consider some of the social impact (and "opportunities") such technologies can bring, it naturally feels like the premise for several short stories.

One: Peaking Under Facial Obfuscation
As I watch news of the "Yellow Vest" riots in Paris, it is inevitable that high-resolution digital video capture of protesters - combined with facial recognition - will mean that many group protest actions will become individually attributable. While the face of the perpetrator may not initially be tied to an identity, a portfolio of digital captures can be compiled and (at some future date) associated with the named individual.

New technologies in the realm of full-color night-vision video capture and advanced infrared heat-based body and face mapping lie the basis of radically better tools for associating captured maleficence to an individual. Combined with the work being done with infrared facial recognition, and we'll soon find that scarfs, balaclavas, or even helmets will cease to protect the identity of the perpetrator.

Two: Perpetual Digital Trail
Many large cities are approaching the point that it is impossible to stand in any public space or thoroughfare and not be captured by at least one video camera. Capitalizing on this, many metropolitan police forces are already able to real-time track a surveilled individual or entity through their networked cameras. In addition, some police forces have already combined such capabilities with facial recognition to quickly spot wanted individuals or suspects in crowds and track their movements across cameras in real-time.

We can expect the density and prevalence of cameras to grow. We can also expect that the video captured from these cameras to increasingly move to the cloud and be retained indefinitely. The AI tooling today already enables us to intelligently stitch together all the video content and construct a historical trail for any person or physical entity.

When combined with (One), it means that in the near future police forces could track (both forward and reverse in time) each suspect - identifying not only the history of travel and events preceding the crime, but also their origination (e.g. home) address... and from there, arrive at an identity conclusion. Imagine doing this for thousands of protesters simultaneously. Obviously, such a capability would also facilitate the capture of facial images of the suspect before they donned any masks or facial obfuscation tools they used during the protest or crime.

Three: Inferring Pending Harm and Stress
As digital video cameras radically increase their capture resolution - moving from an average of 640x480 to 3096x2160 (4k Ultra HD) and beyond over the coming years; facial recognition accuracy will obviously improve, but we can expect other personal traits and characteristics to be accurately inferred.

Studies of human movement and tooling for life-like movements in digital movies naturally lend to the ability to identify changes in an individuals movements and infer certain things. For example, being able to guess the relative weight and flexibility of contents within a backpack being worn by the surveilled individual, the presence of heavy objects being carried within a suit jacket, or changes in contents of a bag carried in-hand.

If we also assume that the surveilled individual will be caught by multiple cameras from different locations, the combination of angles and perspective will further help define the unique characteristics and load of the individual. Police forces could use that intelligence to infer the presence of weapons for example.

Higher resolution monitoring also lends itself to identifying and measuring other more personal attributes of the person being monitored. For example, details on the type and complexity of jewelry being worn, tattoos, or unique visible identifiers.

Using physical tells such as sweat density, head-bobbing (see an earlier blog - Body Worn Camera Technologies), and heart-rate, it will be possible to identify whether the person is stressed, under duress, or has recently exerted themselves.

Four: The Reverse Paradigm
Such technologies are not exclusive to police forces and government departments. It is inevitable that these technologies will also be leveraged by civilians and criminals alike - bringing a rather new dynamic to future policing.

For example, what happens if anti-riot police cannot obfuscate their identity during a riot - despite balaclavas and protective helmets? If every retaliatory baton strike, angered shield charge, tear gas spray, or taser use can be individually attributed to the officer that did it (and the officer can be identified by face capture or uniform number), officers become individually responsible and ultimately accountable for their actions.

Imagine for instance that every office present now had a virtual folder of video captures detailing their actions during the riots. With little effort and likely a little crowd-sourcing, each officer's identity would be discovered and publicly associated with their actions.

It would be reasonable to expect that police officers would adjust their responses to riot situations - and its likely that many would not want to expose themselves to such risk. While it is possible new or existing laws could be used to protect officers from most legal consequences of "doing their job", the social consequences may be a different story.

We've already seen how doxing can severely affect the life and safety of those that are victims, it would be reasonable to assume that some percentage of a rioting population would be only too eager to publish a police officers "crimes" along with all their identity, address, and any other personal data they could find. Would we expect police officers with young families take on the risk of riotous agitators arriving at their families doorstep - looking for vengeance.

Five: Ubiquitous Consumer-led Video Surveillance
A question will inevitably be raised that the ability to construct digital trails or infer motivations and harm will be restricted to police and government entities. After all, they're the ones with the budget and authority to install the cameras.

These challenges may be overcome. For example, new legal test cases may force governments to make such video feeds publicly available - after all, funding is through public money. We've seen such shifts in technology access before - e.g. GPS, satellite mapping, satellite imagery.

An interesting model for consumer video that could become even more complete and ubiquitous video capture (and analytics) may be relatively simple.

Just as today's home security systems have advanced to include multiple internal and external high-resolution video feeds to the cloud, maybe the paradigm changes again. Instead of a managed security monitoring service, things become community based and crowd sourced.

For example, lets say that for each high-resolution video camera you install and connect to a community cloud service, you gain improved access to the accumulated mesh of every other contributing camera. Overlaying that mesh of camera feeds, additional services augment the video with social knowledge and identity information, and the ability to trace movements around an event - just like the police could - for a small fee. The resultant social dynamics would be very interesting... does privacy end at your doorstep? If every crime in a public space is captured and perpetrators labeled, does that make petty and premeditated crime disappear? Does local policing shift to community groups and vigilantes?

Conclusions
Advances in high-resolution digital video cameras and facial recognition will play a critical role in how policing society changes over the next couple of decades.

The anticipated advancements will certainly make it easier for police forces to track, identify, and hold accountable those that perpetuate crimes. But such technologies will also inevitably be likewise utilized by those being policed. While the illustrated scenarios began with the recent riots in France, the repercussions for police forces in Mexico facing wealthy cartels would perhaps be more dire.

It is too early to tell whether the ubiquity of these advancing technologies will tilt the hand in one direction or the other or whether we'll reach a new technology stalemate. Accountability for an individuals actions - backed by proof - feels like the right societal movement, but opens doors to entirely new forms of abuse.

-- Gunter Ollmann