You May Not Have Asked, But The SOC Evolution Answered Anyways

Let’s get the obvious out of the way: The attack surface is growing exponentially and diversely.

Bigger shark, same small boat

The environments, platforms, services, regions and time zones that constitute modern enterprise operations and drive digital transformation for business continue to require increasing specialization and expertise beyond current in-house capabilities. Through a security lens, enterprise attack surfaces are expanding beyond the business’ ability to protect.

Meanwhile, global hiring and retention of security expertise continues to be a weak spot, and direct access to specialized security knowledge and experience is becoming increasingly difficult and costly. And while all that is going on, the volume, duration, pace and sophistication of attacks continues to increase and require significant acceleration in SOC response times and durability — and subsequent autonomous response systems.

Saying we’re in a conundrum is vastly understating things.

The security industry is at the gate of a forced SOC evolution, and as you can see, pressure is coming from all directions to drive that change.

The more things change, the more they stay the same

Plenty has happened that has tried to look like an evolution. For the last decade the security industry that powers SOCs has fixated on automation as the key to alleviating some of the pressures. But after a decade, have things really changed?

SOAR was a brief shining light that has come and mostly gone, having been absorbed back into SIEM, as the legacy SIEM vendors acquired dedicated SOAR vendors to make up for their shortcomings in human workflow automation. This didn’t solve much, as analysts were more or less left in the lurch. They faced the same automation integration challenges, only now they’re locked into a single vendor (where previously an “independent” SOAR offered the prospect of multi-vendor connectors and flexibility to operate independently of SIEM lock-in).

And that’s not the end of our automation woes, either. Automation, on its best day, is still too playbook-oriented. To get things done, experts have to essentially write scripts for each new system, connector and application in an enterprise. If we had set out to create librarians out of analysts, that’s an area our industry could say it had actually achieved success in.

But in all seriousness, we’re caught in a linear script development cycle and automation hasn’t yielded the reduction in analyst workloads that we so desperately need.

I’d like to get off the ride, please

So how do we break the cycle? I can identify two major breakthroughs that will move the needle forward for the SOC evolution.

First, the successful implementation and use of AI “smart” orchestration systems within the SOC.

I’m sure many SOC analysts and CISO’s are jaded from past promises, but the reality is that AI and ML approaches have matured significantly over the last year, and have reached the inflection point of their “hockey stick” usefulness trajectory and the value they can bring. I think as an industry it’s time we start to move past our fear of turning on automated response and protection capabilities that are powered by this new generation of AI and ML. By embracing it, SOCs will become much more effective at detection, which will lead to a reduction in the number of distinct alerts and false positives (put that in the win column for reducing analyst workloads).

Second breakthrough: The ability to tap a global community of contributors via marketplace ecosystems, or more simply put, sharing is caring.

Detection-as-code, policy-as-code, blah-as-code has redefined content development and vendor-proprietary product-dependent content. Platform-independent content (ranging from alerts, threat detection, playbooks, etc.) is rapidly and readily available from a global array of sources, and availability will continue to increase. The ability to tap a global pool of expertise is more prevalent than ever and it feels like the gig economy is finally coming to the security world via the SOC. I think this would have surprised many people just a few years ago, but in the wise words of one Jim Carrey — “desperation is a necessary ingredient to learning anything.”

I don’t care how, I want it now

Well, you can’t have it…yet. But you can start. Both “smart” machine-intelligence and content marketplaces directly address the pressure points previously mentioned, but the industry is still in early stages of the SOC evolution. Right now organizations have to take a look at their SOC and decide how they’re going to reorganize and prioritize to discover and implement the people, tools and partners they’ll need to usher in the evolution.

There are some philosophical hurdles to be overcome, but I believe business needs will drive the pace of change. It used to be the case that penetration testing was in-house only, then extended to trusted vendors managed under restrictive agreements, and on to industry-accredited providers, and now businesses can tap broad communities of bug-bounty-based individual contractors and cloud-based automated attack simulators. If we managed those industry changes, I’m pretty sure we can manage the same for incident response and investigation.

-- Gunter Ollmann

First Published: Medium - December 9, 2021

The Diet Pill Security Model

The information security industry, lacking social inhibitions, generally rolls its eyes at anything remotely hinting to be a "silver bullet" for security. Despite that obvious hint, marketing teams remain undeterred at labeling their companies upcoming widget as the savior to the next security threat (or the last one - depending on what's in the news today).

I've joked in the past that the very concept of a silver bullet is patently wrong - as if silver would make a difference. No, the silver bullet must in fact be water. After all, chucking a bucket of water on a compromised server is guaranteed to stop the attacker dead in their tracks.

Bad jokes aside, the fundamental problem with InfoSec has less to do with the technology being proposed or deployed to prevent this or that class of threat, and more to do with the lack of buyers willing to change their broken security practices and compliment their new technology investment.

Too many security buyers are effectively looking for the diet pill solution. Rather than adjusting internal processes and dropping bad practices, there is eternal hope that the magical security solution will fix all ills and the business can continue to binge on deep-fried Mars bars and New York Cheesecakes.

As they say, "hope springs eternal".

Just as a medical doctor's first-line advice is to exercise more and eat healthily, our corresponding security advice is harden your systems and keep up to date with patching.

Expecting the next diet pill solution to cure all your security ills is ludicrous. Get the basics done right, and get them right all the time first, and expand from there.

-- Gunter

The Missing Piece of the Security Conference Circuit

So far this year I think I've attended 20+ security conferences around the world - speaking at many of them. Along the way I got to chat with hundreds of attendees and gather their thoughts on what they hoped to achieve or learn at each of these conferences.

In way too many cases I think the conference organizers have missed the mark.

I'd like to offer the following thoughts and feedback to the people organizing and facilitating these conferences (especially those catering to local security professionals):

• Attendees have had enough of stunt hacking presentations. By all means, throw in one or two qualified speakers on some great stunt hack - but use them as sparingly as keynotes.
• Highly specialized - border-line stunt hacking topics - disenfranchise many of the attendees. Sure, it's fun to have a deep-dive hacking session on voting machines, smart cars, etc. but when every session is focused on (what is essentially an) "edge" security device that most attendees will never be charged with attacking or defending... it's no longer overwhelming, it becomes noise that can't be applied in "real-life" for the majority of attendees.
• As an industry we're desperately trying to engage those entering the job market and "sell" them on our security profession. Trinket displays of security (e.g. CTF, lock-picking) sound more interesting to people already in security... and much less so to those just entering the job market. Lets face it, no matter how much they enjoy picking locks, it's unlikely a qualification for first-line SOC analysts. Even for those that have been in the industry for a few years, these cliche trinket displays of security "skill" have become tired... and look like wannabe Def Cons.
• Most attendees really want to LEARN something that they can APPLY to their job. They're looking for nuggets of smartness that can be used tomorrow in the execution of their job.

Here's a few thoughts for security (/hacker) conference organizers:

• Have a track (or two) specifically focused on attack techniques (or defense techniques) where each presented session can clearly say what new skill or technique the attendee will have acquired as the leave the hallowed chamber of security knowledge goodness. This may be as simple as escalating existing skills e.g. "if you're a 5 on XSS today, by the end of the session you'll have reached a 7 in XSS against SAP installations", or "you'll learn how to use Jupyter Notebooks for managing threat hunt collaboration". The objective is simple: an attendee should be able to apply new skills and expertise tomorrow... at their day job.
• Get more people presenting, and presenting for less time. Encourage a broader range of speakers to present on practical security topics. I think many attendees would love to see a "open mic" speaker track where security professionals (new and upcoming) can deep-dive present on interesting security topics and raise questions to attendees for help/guidance/answers. For example, the speaker has deep-dived into blocking spear-phishing emails using XYZ product but identified that certain types of email vectors evade it... they present proposals on improvement... and the attendees add their collective knowledge. It encourages interaction and (ideally) helps to solve real-world problems.
• An iteration of the idea above, but focused on students, those job hunting for security roles, or on their first rung of the security ladder... a track where they can present on a vetted security topic where a panel of security veterans that evaluate the presentation - the content and the delivery - and provide rewards. In particular, I'd love to see (and ensure) that the presentation is recorded, and the presentation material is available for download (including maybe a backup whitepaper). Why? Because I'd encourage these speakers to reference and link to these resources (and conference awards) in their resumes/CV's so they can differentiate themselves in the hiring market.
• Finally, I'd encourage (and offer myself up for participation) a track for practicing and refining interview techniques. It's daunting for all new starters in our industry to successfully navigate an interview with experienced and battle wary security professionals. It takes practice, guidance, and encouragement. In reality, starter interviewees have less than 15 minutes to establish their technical depth, learning capability, and group compatibility. On the flip-side, learning and practice sessions for technical security hiring managers on overcoming biases and encouraging diversity. We're an industry full of introverts and know-it-all's that genuinely want to help... but we all need a little help and coaching in this critical area.

-- Gunter Ollmann

The Security Talent Gap is Misunderstood and AI Changes it All

Despite headlines now at least a couple years old, the InfoSec world is still (largely) playing lip-service to the lack of security talent and the growing skills gap.

The community is apt to quote and brandish the dire figures, but unless you're actually a hiring manager striving to fill low to mid-level security positions, you're not feeling the pain - in fact there's a high probability many see problem as a net positive in terms of their own employment potential and compensation.

I see today's Artificial Intelligence (AI) and the AI-based technologies that'll be commercialized over the next 2-3 years as exacerbating the problem - but also offering up a silver-lining.

I've been vocal for decades that much of the professional security industry is and should be methodology based. And, by being methodology based, be reliably repeatable; whether that be bug hunting, vulnerability assessment, threat hunting, or even incident response. If a reliable methodology exists, and the results can be consistently verified correct, then the process can be reliably automated. Nowadays, that automation lies firmly in the realm of AI - and the capabilities of these newly emerged AI security platforms are already reliably out-performing tier-one (e.g. 0-2 years experience) security professionals.

In some security professions (such as auditing & compliance, penetration testing, and threat hunting) AI-based systems are already capable of performing at tier-two (i.e. 2-8 years experience) levels for 80%+ of the daily tasks.

On one hand, these AI systems alleviate much of the problem related to shortage and global availability of security skills at the lower end of the security professional ladder. So perhaps the much touted and repeated shortage numbers don't matter - and extrapolation of current shortages in future open positions is overestimated.

However, if AI solutions consume the security roles and daily tasks equivalency of 8-year industry veterans, have we also created an insurmountable chasm for resent graduates and those who wish to transition and join the InfoSec professional ladder?

While AI is advancing the boundaries of defense and, frankly, an organizations ability to detect and mitigate threats has never been better (and will be even better tomorrow), there are still large swathes of the security landscape that AI has yet to solve. In fact many of these new swathes have only opened up to security professionals because AI has made them available.

What I see in our AI Security future is more of a symbiotic relationship.

AI's will continue to speed up the discovery and mitigation of threats, and get better and more accurate along the way. It is inevitable that tier-two security roles will succumb and eventually be replaced by AI. What will also happen is that security professional roles will change from the application of tools and techniques into business risk advisers and supervisors. Understanding the business, communicating with colleagues in other operational facets, and prioritizing risk response, are the intangibles that AI systems will struggle with.

In a symbiotic relationship, security professionals will guide and communicate these operations in terms of business needs and risk. Just as Internet search engines have replaced the voluminous Encyclopedia Britannica and Encarta, and the Dewey Decimal system, Security AI is evolving to answer any question a business may raise about defending their organization - assuming you ask the right question, and know how to interpret the answer.

With regards to the skills shortage of today - I truly believe that AI will be the vehicle to close that gap. But I also think we're in for a paradigm change in who we'll be welcoming in to our organizations and employing in the future because of it.

I think that the primary beneficiaries of these next generation AI-powered security professional roles will not be recent graduates. With a newly level playing field, I anticipate that more weathered and "life experienced" people will assume more of these roles.

For example, given the choice between a 19 year-old freshly minted graduate in computer science, versus a 47 year-old woman with 25 years of applied mechanical engineering experience in the "rust belt" of the US,... those life skills will inevitably be more applicable to making risk calls and communicating them to the business.

In some ways the silver-lining may be the middle-America that has suffered and languished as technology has moved on from coal mining and phone-book printing. It's quite probable that it will become the hot-spot for newly minted security professionals - leveraging their past (non security) professional experiences, along with decades of people or business management and communication skills - and closing the missing security skills gap using AI.

-- Gunter

Lock Picking at Security Conferences

Both new and returning attendees at technical security conferences are often puzzled by the presence of lock picking break-out areas and the gamut of hands-on tutorials. For an industry primarily focused on securing electronic packets of ones and zeros, an enthusiasm for manual manipulation of mechanical locks seems out of place to many.

Over the years, I’ve heard many reasons and justifications for the presence of lock picking villages, the hands-on training, and the multitude of booths selling the tools of the trade. The answers vary considerably and tend to be weighted by how much of a tinkerer or hacker the respondent thinks they are.

The reality – I think – can be boiled down to two primary reasons.

Like most longtime security professionals who now take to the stage to educate attendees on the fragility of the cyber-security domain, or attempt to mentor and guide the in-bound generation of attackers and defenders, locks and lock picking serve as a valuable teaching aid. As such, through our influence, we encourage people to tinker and learn.

By examining how mechanical locks operate and how they have evolved to counter each new picking technique used to subvert earlier models, cyber-security professionals begin to appreciate three fundamentals of security:

1. Attackers learn by dissecting and studying the intricacies of the defenses before them and must practice, practice, practice to defeat them. 
2. Defenders must understand the tools and methodologies that the attackers avail themselves of if they are to devise and deploy better defenses, and 
3. No matter how well thought-out in advance, the limitations of fabrication tolerances and the environments with which the security technology must operate within will introduce new flaws and vectors for attack.

These are incredibly important lessons that must be learned. Would-be professionals seeking to get into penetration testing, red teaming, or reverse engineering can’t just pick up the latest Hacking Exposed edition and complete online Q&A exams – they must roll-up their sleeves and accumulate the hours of hands-on experience of both failures and successes, and build that muscle-memory. Would-be defenders can’t just read the operations manuals of the devices they’ll be entrusted to protect, or sit through vendor training courses on how to operate threat detection systems – they must learn the tools of the attackers and (ideally) gain basic proficiency in their use if they’re to make valuable contributions to defense. Meanwhile, the third point is where both attackers and defender need to learn humility – no matter how well we think we know a system or how often we’ve practiced against a technology, subtle flaws and unexpected permutations may undermine our best efforts through no fault of our own skills.

As a teaching aid, locks and lock picking are a tactile means of understanding the foibles of cyber security.

But there is a second reason… because it’s exciting and fun!

Lock picking feeds into the historical counter-culture of hacking. There’s a kind of excitement learning how to defeat something near the edge of legitimacy – an illicit knowledge that for centuries has been the trade-craft of criminals.

With a few minutes of guidance and practice, the easiest locks begin to pop open and the hacker is drawn to the challenge of a harder lock, and so on. As frustrations grow, the reward of the final movement and pop of the lock is often as stimulating as scoring a goal in some kind of popular uniformed team sport.

The skills associated with mastering lock picking however have little translation to being a good hacker – except perhaps the single-minded intensity and tenaciousness to solve technical changes.
I have noticed that there are a disproportionate number of hackers who are both accomplished lock pickers, (semi) professional magicians, and wall-flower introverts. Arguably, locking picking (and magic tricks) may be the hackers best defense at uncomfortable social events. Rather than have an awkward conversation about sports or pop culture, it’s often time to whip out a lock and a pack of picks, and teach instead of prattle.

-- Gunter Ollmann

Deception Technologies: Deceiving the Attacker or the Buyer?

Deception technologies, over the last three-ish years, have come into vogue; with more than a dozen commercial vendors and close to a hundred open source products available to choose from. Solutions range from local host canary file monitoring, through to autonomous self-replicating and dynamic copies of the defenders network operating like an endless hall of mirrors.

The technologies employed for deception purposes are increasingly broad - but the ultimate goal is for an attacker to be deceived into tripping over or touching a specially deposited file, user account, or networked service and, in doing so, sounding an alarm so that the defenders can start to... umm... well..., often it's not clear what the defender is supposed to do. And that's part of the problem with the deception approach to defense.

I'm interested, but deeply cautious about the claims of deception technology vendors, and so should you be. It's incredibly difficult to justify their expense and understand their overall value when incorporated in to a defense in depth strategy.

There have been many times over the last couple of decades I have recommended to my clients and businesses a quick and dirty canary solution. For example, adding unique user accounts that appear at the start and end of your LDAP, Active Directory, or email contacts list - such that if anyone ever emails those addresses, you know you've been compromised. And similar canary files or shares for detecting the presence of worm outbreaks. But, and I must stress the "but", those solutions only apply to organizations that have not invested in the basics of network hygiene and defense in depth.

Honeypots, Honeynets, canaries, and deception products are HIGHLY prone to false positives. Vendors love to say otherwise, but the practical reality is that there's a near infinite number of everyday things that'll set them off - on hole or in part. For example:

• Regular vulnerability scanning,
• Data backups and file recovery,
• System patching and updates,
• Changes in firewall or VPN policies,
• Curious employees,
• Anti-virus scanners and suite updates,
• On-premise enterprise search systems,
• Cloud file repository configuration changes and synchronization,

The net result being either you ignore or turn off the system after a short period of time, or you swell your security teams ranks and add headcount to continually manage and tune the system(s).

If you want my honest opinion though, I'd have to say that the time for deception-based products has already past. 

If you're smart, you've already turned on most of the logging features of your desktop computers, laptops, servers, and infrastructure devices, and you're capturing all file, service, user, and application access attempts. You're therefore already capturing more of the raw information necessary to detect any threat your favorite deception technology is proposing to identify for you. Obviously, the trick is being able to process those logs for anomalies and responding to the threat.

This year alone the number of automated log analytics platforms and standalone products that employ AI and machine learning that are capable of real-time (or, worst case, "warm") detection of threats, has grown to outnumber all the tools in the Deception solution category - and they do it cheaper, more efficiently, and with less human involvement. 

Deception vendors were too slow. The log analytics vendors incorporated more advanced detection systems, user behavioral analytics, and were better able to mitigate the false positive problems - and didn't require additional investment in host agents and network appliances to collect the data that the deception technologies needed.

As an enterprise security buyer, I think you can forget about employing deception technologies and instead invest in automated log analytics. Not only will you cover the same threats, but the log analytics platforms will continue to innovate faster and cover a broader spectrum of threats and SecOps without the propensity of false positives.

-- Gunter Ollman

Allowing Vendors VPN access during Product Evaluation

For many prospective buyers of the latest generation of network threat detection technologies it may appear ironic that these AI-driven learning systems require so much manual tuning and external monitoring by vendors during a technical “proof of concept” (PoC) evaluation.

Practically all vendors of the latest breed of network-based threat detection technology require varying levels of network accessibility to the appliances or virtual installations of their product within a prospect’s (and future customers) network. Typical types of remote access include:

• Core software updates (typically a pushed out-to-in update)
• Detection model and signature updates (typically a scheduled in-to-out download process)
• Threat intelligence and labeled data extraction (typically an ad hoc per-detection in-to-out connection)
• Cloud contribution of abstracted detection details or meta-data (often a high frequency in-to-out push of collected data)
• Customer support interface (ad hoc out-to-in human-initiated supervisory control)
• Command-line technical support and maintenance (ad hoc out-to-in human-initiated supervisory control)

Depending upon the product, the vendor, and the network environment, some or all of these types of remote access will be required for the solution to function correctly. But which are truly necessary and which could be used to unfairly manually manipulate the product during this important evaluation phase?

To be flexible, most vendors provide configuration options that control the type, direction, frequency, and initialization processes for remote access.

When evaluating network detection products of this ilk, the prospective buyer needs to very carefully review each remote access option and fully understand the products reliance and efficacy associated with each one. Every remote access option eventually allowed is (unfortunately) an additional hole being introduced to the buyers’ defenses. Knowing this, it is unfortunate that some vendors will seek to downplay their reliance upon certain remote access requirements – especially during a PoC.

Prior to conducting a technical evaluation of the network detection system, buyers should ask the following types of questions to their prospective vendor(s):

• What is the maximum period needed for the product to have learned the network and host behaviors of the environment it will be tested within?
• During this learning period and throughout the PoC evaluation, how frequently will the product’s core software, detection models, typically be updated? 
• If no remote access is allowed to the product, how long can the product operate before losing detection capabilities and which detection types will degrade to what extent over the PoC period?
• If remote interactive (e.g. VPN) control of the product is required, precisely what activities does the vendor anticipate to conduct during the PoC, and will all these manipulations be comprehensively logged and available for post-PoC review?
• What controls and data segregation are in place to secure any meta-data or performance analytics sent by the product to the vendor’s cloud or remote processing location? At the end of the PoC, how does the vendor propose to irrevocably delete all meta-data from their systems associated with the deployed product?
• If testing is conducted during a vital learning period, what attack behaviors are likely to be missed and may negatively influence other detection types or alerting thresholds for the network and devices hosted within it?
• Assuming VPN access during the PoC, what manual tuning, triage, or data clean-up processes are envisaged by the vendor – and how representative will it be of the support necessary for a real deployment?

It is important that prospective buyers understand not only the number and types of remote access necessary for the product to correctly function, but also how much “special treatment” the PoC deployment will receive during the evaluation period – and whether this will carry-over to a production deployment.

As vendors strive to battle their way through security buzzword bingo, in this early age of AI-powered detection technology, remote control and manual intervention in to the detection process (especially during the PoC period) may be akin to temporarily subscribing to a Mechanical Turk solution; something to be very careful of indeed.

-- Gunter Ollmann, Founder/Principal @ Ablative Security

Edge Computing, Fog Computing, IoT, and Securing them All

The oft used term “the Internet of Things” (IoT) has expanded to encapsulate practically any device (or “thing”) with some modicum of compute power that in turn can connect to another device that may or may not be connected to the Internet. The range of products and technologies falling in to the IoT bucket is immensely broad – ranging from household refrigerators that can order and restock goods via Amazon, through to Smart City traffic flow sensors that feed navigation systems to avoid jams, and even implanted heart monitors that can send emergency updates via the patient’s smartphone to a cardiovascular surgeon on vacation in the Maldives.

The information security community – in fact, the InfoSec industry at large – has struggled and mostly failed to secure the “IoT”. This does not bode well for the next evolutionary advancement of networked compute technology.

Today’s IoT security problems are caused and compounded by some pretty hefty design limitations – ranging from power consumption, physical size and shock resistance, environmental exposure, cost-per-unit, and the manufacturers overall security knowledge and development capability.

The next evolutionary step is already underway – and exposes a different kind of threat and attack surface to IoT.

As each device we use or the components we incorporate in to our products or services become smart, there is a growing need for a “brain of brains”. In most technology use cases, it makes no sense to have every smart device independently connecting to the Internet and expecting a cloud-based system to make sense of it all and to control.

It’s simply not practical for every device to use the cloud the way smartphones do – sending everything to the cloud to be processed, having their data stored in the cloud, and having the cloud return the processed results back to the phone.

Consider the coming generation of automobiles. Every motor, servo, switch, and meter within the vehicle will be independently smart – monitoring the devices performance, configuration, optimal tuning, and fault status. A self-driving car needs to instantaneously process this huge volume of data from several hundred devices. Passing it to the cloud and back again just isn’t viable. Instead the vehicle needs to handle its own processing and storage capabilities – independent of the cloud – yet still be interconnected.

The concepts behind this shift in computing power and intelligence are increasingly referred to as “Fog Computing”. In essence, computing nodes closest to the collective of smart devices within a product (e.g. a self-driving car) or environment (e.g. a product assembly line) must be able to handle he high volumes of data and velocity of data generation, and provide services that standardize, correlate, reduce, and control the data elements that will be passed to the cloud. These smart(er) aggregation points are in turn referred to as “Fog Nodes”.

Source: Cisco

Evolutionary, this means that computing power is shifting to the edges of the network. Centralization of computing resources and processing within the Cloud revolutionized the Information Technology industry. “Edge Computing” is the next advancement – and it’s already underway.

If the InfoSec industry has been so unsuccessful in securing the IoT, what is the probability it will be more successful with Fog Computing and eventually Edge Computing paradigms?

My expectation is that securing Fog and Edge computing environments will actual be simpler, and many of the problems with IoT will likely be overcome as the insecure devices themselves become subsumed in the Fog.

A limitation of securing the IoT has been the processing power of the embedded computing system within the device. As these devices begin to report in and communicate through aggregation nodes, I anticipate those nodes to have substantially more computing power and will be capable of performing securing and validating the communications of all the dumb-smart devices.

As computing power shifts to the edge of the network, so too will security.

Over the years corporate computing needs have shifted from centralized mainframes, to distributed workstations, to centralized and public cloud, and next into decentralized Edge Computing. Security technologies and threat analytics have followed a parallel path. While the InfoSec industry has failed to secure the millions upon millions of IoT devices already deployed, the cure likely lies in the more powerful Fog Nodes and smart edges of the network that do have the compute power necessary to analyze threats and mitigate them.

That all said, Edge Computing also means that there will be an entirely new class of device isolated and exposed to attack. These edge devices will not only have to protect the less-smart devices they proxy control for, but will have to be able to protect themselves too.

Nobody ever said the life of an InfoSec professional was dull.

The Future of Luxury Car Brands in a Self-Driving City

For the automotive manufacturing industry, the next couple of decades are going to be make or break for most of the well known brand names we're familiar with today. 

With the near term prospect of "self-driving" cars and city-level smart traffic routing (and monitoring) infrastructure fundamentally changing the way in which we drive, and the shift in city demographics that promotes a growing move away from wanting (or being able to afford) a personal vehicle, it should be clear to all that the motoring practices of the last century are on a trajectory to disappear pretty quickly.

As self-driving cars eventually negate the "love of driving" and city traffic routing and control systems begin to rigorously enforce variable speed limits, congestion charging, and overall traffic management, the personal car becomes more and more just another impersonal transport system. If that's likely the case (or even partially the case), then what does the future hold for the manufacturers of luxury cars?

Earlier this month I spent a week in Bavaria, Germany, visiting customers and prospects. The economies of cities like Stuttgart and Munich fundamentally revolve around the luxury automotive industry. Companies like BMW, Audi, and Porsche define the standard in personal vehicle luxury and generally lead the world in technical innovation (especially in safety features). Speaking with locals around Bavaria there is a very real fear that the next two decades could see the fall and eventual demise of these brands.

If the act of "driving" is completely replaced with computer control systems and the vehicle itself eventually becomes a commodity (because every vehicle performs the same way, travels at the same speeds, and is carefully governed by city traffic management systems), luxury vehicle "performance" is no longer a perceived value. As the mandated vehicle safety designs are achieved by all manufacturers and there's only a small percentage difference between the best and the worst (yet all getting "five stars"), advanced safety innovation no longer becomes a distinguishing factor. Finally, as Millennials (and the majority of city-bound Generation X and Y) give up the love, desire, and financial capability to own a personal vehicle - and instead seek "on-demand" public transport systems the likes that Uber and its kin will spawn - then "luxury" becomes a style choice without a premium.

Like those Bavarians I spoke with, these luxury car manufacturers are going to have to change dramatically if they are to continue to be the brands they are today. Despite all the technical innovation they've been renowned for over the last century, it does appear that they are late to the party and need to dramatically change their businesses in pretty short order.

As a BMW owner myself, I'm surprised at how far the company appears to be behind the global changes. I'd have thought that such a technically innovative company would have grasped the social and economic affects on luxury vehicle sales to city dwellers for the coming decade or two. While BMW (and other luxury car brands) have doubled down on vehicle performance, emission controls, renewable energy, and environmentally friendly design, it feels like they've been caught flat-footed in the innovation and desires of people (and city planners) to remove themselves from being the weakness behind the steering wheel... and the implication on all luxury vehicle brands.

I'm positive that the engineers at BMW and other traditionally innovative vehicle manufacturers have many relevant technologies tested and maybe shelved in their laboratories and around test tracks.

While I doubt that "luxury" will form less of a vehicles buying decision in the future - especially when the trend is towards fleet management of such vehicles (e.g. taxis, delivery, etc.) - I think that, for these companies to survive, they're going to have to become "technology companies".

Although late to the party, present-day luxury vehicle manufacturers can transform in to strong technology companies. For example, some opportunities could include:

• With several decades of technical safety R&D innovation (e.g. collision avoidance, LADAR, automated parking, route guidance systems, land management, sleepy driver recognition, etc.) they already have the credentials and respect in the industry (and with consumers) as being the research leaders... so why not bundle up these safety features and license them under their brands. For example, the future Google self-driving car... music by Bose, safety by BMW.
• As designers of engines (combustion, hybrid, and electric) they have decades of experience in design and performance. That could translate in to innovating city-wide refueling management platforms and systems.
• "Smart Cities" are still mostly a desire rather than a reality. There is huge opportunity for proven technology companies to come in and define the rules, criteria, monitoring, and management of city-wide traffic control systems. Detailed knowledge of vehicle performance, capabilities, and safety controls whole be an ideal platform for building upon.
• Regardless of just how many driver-less cars come to market over the coming decades, there are still going to be hundreds of millions of cars that were never built or designed to be "driver-less". There is an obvious requirement for supplemental or conversion kits for older vehicles - not just their own models.

The list above could be expanded considerably and I doubt that similar thoughts haven't also been discussed at various points in the last half-decade by the luxury brands themselves. However it would seem to me that now is a time of action.

It'll be very interesting to see how these luxury vehicle manufacturers reinvent themselves. If they have the funds now, then not only should they continue to innovate down safety technology paths, but they should probably be looking down the acquisition path... bringing into the fold new tech companies specializing in fleet and city vehicle management, taxi and courier management and control systems, city traffic monitoring and control systems, and maybe even a new generation of refueling station.

Watching the Watchers Watching Your Network

It seems that this last holiday season didn’t bring much cheer or goodwill to corporate security teams. With the public disclosure of remotely exploitable vulnerabilities and backdoors in the products of several well-known security vendors, many corporate security teams spent a great deal of time yanking cables, adding new firewall rules, and monitoring their networks with extra vigilance.

It’s not the first time that products from major security vendors have been found wanting.

It feels as though some vendor’s host-based security defenses fail on a monthly basis, while network defense appliances fail less frequently – maybe twice per year. At least that’s what a general perusal of press coverage may lead you to believe. However, the reality is quite different. Most security vendors fix and patch security weaknesses on a monthly basis. Generally, the issues are ones that they themselves have identified (through internal SDL processes or the use of third-party code reviews and assessment) or they are issues identified by customers. And, every so often, critical security flaws will be “dropped” on the vendor by an independent researcher or security company that need to be fixed quickly.

Two decades ago, the terms “bastion host”, DMZ, and “firewall” pretty much summed up the core concepts of network security, and it was a simpler time for most organizations – both for vendors and their customers. The threat spectrum was relatively narrow, the attacks largely manual, and an organization’s online presence consisted of mostly static material. Yet, even then, if you picked up a book on network security you were instructed in no short order that you needed to keep your networks separate; one for the Internet, one for your backend applications, one for your backups, and a separate one for managing your security technology.

Since that time, many organizations have either forgotten these basic principles or have intentionally opted for riskier (yet cheaper) architectures and just hoping that their protection technologies are up to the task. Alas, as the events of December 2015 have shown us, every device added to a network introduces a new set of security challenges and weaknesses.

From a network security perspective, when looking at the architecture of critical defenses, there are four core principles:

1. Devices capable of monitoring or manipulating network traffic should never have their management interfaces directly connected to the Internet. If these security devices need to be managed over the Internet it is critical that only encrypted protocols be used, multi-factor authentication be employed, and that approved in-bound management IP addresses be whitelisted at a minimum. 
2. The management and alerting interfaces of security appliances must be on a “management” network – separated from other corporate and public networks. It should not be possible for an attacker who may have compromised a security device to leverage the management network to move laterally onto other guest systems or provide a route to the Internet. 
3. Span ports and network taps that observe Internet and internal corporate traffic should by default only operate in “read-only” mode. A compromised security monitoring appliance should never be capable of modifying network traffic or communicating with the Internet from such an observation port. 
4. Monitor your security products and their management networks. Security products (especially networking appliances such as core routers, firewalls, and malware defenses) will always be a high-value target to both external and internal attackers. These core devices and their management networks must be continuously monitored for anomalies and audited. 

In an age where state-sponsored reverse engineers, security research teams, and online protagonists are actively hunting for flaws and backdoors in the widely deployed products of major security vendors as a means of gaining privileged and secret access to their target’s networks, it is beyond prudent to revisit the core tenets of secure network architecture.

Corporate security teams and network architects should assume not only that new vulnerabilities and backdoors will be disclosed throughout the year, but that those holes may have been accessible and exploited for several months beforehand. As such, they should adopt a robust defense-in-depth strategy including “watchers watching watchers.”

Shodan's Shining Light

The Internet is chock full of really helpful people and autonomous systems that silently probe, test, and evaluate your corporate defenses every second of every minute of every hour of every day. If those helpful souls and systems aren’t probing your network, then they’re diligently recording and cataloguing everything they’ve found so others can quickly enumerate your online business or list systems like yours that are similarly vulnerable to some kind of attack or other.

Back in the dark ages of the Internet (circa the 20th century) everyone had to run their own scans to map the Internet in order to spot vulnerable systems on the network. Today, if you don’t want to risk falling foul of some antiquated hacking law in some country by probing IP addresses and shaking electronic hands with the services you encounter, you can easily find a helpful soul that’s figured it all out on your behalf and turn on the faucet of knowledge for a paltry sum.

One of the most popular services to shine light on and enumerate the darkest corners of the Internet is Shodan. It’s a portal-driven service through which subscribers can query its vast database of IP addresses, online applications and service banners that populate the Internet. Behind the scenes, Shodan’s multiple servers continually scan the Internet, enumerating and probing every device they encounter and recording the latest findings.

As an online service that diligently catalogues the Internet, Shodan behaves rather nicely. Servers that do the scanning aren’t overly aggressive and provide DNS information that doesn’t obfuscate who and what they are. Additionally, they are little more troublesome than Google in its efforts to map out Web content on the Internet.

In general, most people don’t identify what Google (or Microsoft, Yahoo or any other commercial search engine) does as bad, let alone illegal. But if you are familiar with the advanced search options these sites offer or read any number of books or blogs on “Google Dorks,” you’ll likely be more fearful of them than something with limited scope like Shodan.

Unfortunately, Shodan is increasingly perceived as a threat by many organizations. This might be due to its overwhelming popularity or its frequent citation amongst the infosec community and journalists as a source of embarrassing statistics. Consequently, security companies like Check Point have included alerts and blocking signatures in a vain attempt to thwart Shodan and its ilk.

On one hand, you might empathize with many organizations on the receiving end of a Shodan scan. Their Internet-accessible systems are constantly probed, their services are enumerated, and every embarrassing misconfiguration or unpatched service is catalogued and could be used against them by evil hackers, researchers and journalists.

In some realms, you’ll also hear that the bad guy competitors to Shodan (e.g. cyber criminals mapping the Internet for their own financial gain) are copying the scanning characteristics of Shodan so the target’s security and incident response teams assume it’s actually the good guys and ignore the threat.

On the other hand, with it being so easy to modify the scanning process – changing scan types, modifying handshake processes, using different domain names, and launching scans from a broader range of IP addresses – you’d be forgiven for thinking that it’s all a bit of wasted effort… about as useful as a “keep-off-the-grass” sign in Hyde Park.

Although “robots.txt” in its own way serves as a similarly polite request for commercial Web search scanners to not navigate and cache pages on a site, it is most often ignored by scanning providers. It also serves as a flashing neon arrow that directs hackers and security researchers to the more sensitive content.

It’s a sad indictment of current network security practices that a reputable security vendor felt the need and justification to add detection rules for Shodan scans and that their customer organizations may feel more protected for implementing them.

While the virtual “keep-off-the-grass” warning isn’t going to stop anyone, it does empower the groundskeeper to shout, “Get off my land!” (in the best Cornish accent they can muster) and feel justified in doing so. In the meantime, the plague of ever-helpful souls and automated systems will continue to probe away to their hearts content.

Battling Cyber Threats Using Lessons Learned 165 Years Ago

When it comes to protecting the end user, the information security community is awash with technologies and options. Yet, despite the near endless array of products and innovation focused on securing that end user from an equally broad and expanding array of threats, the end user remains more exposed and vulnerable than at any other period in the history of personal computing.

Independent of these protection technologies (or possibly because of them), we’ve also tried to educate the user in how best (i.e. more safely) to browse the Internet and take actions to protect themselves. With a cynical eye, it’s almost like a government handing out maps to their citizens and labeling streets, homes, and businesses that are known to be dangerous and shouldn’t be visited – because not even the police or military have been effective there.

Today we instruct our users (and at home, our children) to be careful what they click-on, what pages or sites they visit, what information they can share, and what files they should download. These instructions are not just onerous and confusing, more often than not they’re irrelevant – as, even after following them to the letter, the user can still fall victim.

The fact that a user can’t click on whatever they want, browse wherever they need to, and open what they’ve received, should be interpreted as a mile-high flashing neon sign saying “infosec has failed and continues to fail” (maybe reworded with a bunch of four-letter expletives for good measure too).

For decades now thousands of security vendors have brought to market technologies that, in effect, are predominantly tools designed to fill vulnerable and exploited gaps in the operating systems lying at the core of devices the end users rely upon. If we’re ever to make progress against the threat and reach the utopia of users being able to “carelessly” using the Internet, those operating systems must get substantially better.

In recent years, great progress has been made in the OS front – primarily smartphone OS’s. The operating systems running on our most pocket-friendly devices are considerably more secure than those we rely upon for our PC’s, notebooks, or servers at home or work. There’s a bunch of reasons why of course – and I’ll not get in to that here – but there’s still so much more that can be done.

I do believe that there are many lessons that can be learned from the past; lessons that can help guide future developments and technologies. Reaching back a little further in to the past than usual – way before the Internet, and way before computers – there are a couple of related events that could shine a brighter light on newer approaches to protecting the end user.

Back in 1850 a Hungarian doctor named Ignaz Semmelweis was working in the maternity clinic at the General Hospital in Vienna where he noted that many women in maternity wards were dying from puerperal fever - commonly known as childbed fever. He studied two medical wards in the hospital – one staffed by all male doctors and medical students, and the other by female midwifes – and counted the number of deaths in each ward. What he found was that death from childbirth was five times higher in the ward with the male doctors.

Dr. Semmulweis tested numerous hypothesis as to the root cause of the deadly difference – ranging from mothers giving birth on their sides versus their backs, through to the route priests traversed the ward and the bells they rang. It appears that his Eureka moment came after the death of a male pathologist who, upon pricking his finger while doing an autopsy on a woman who had died of childbed fever, had succumbed to the same fate (apparently being a pathologist in the mid-19^th century was not conducive to a long life). Joining the dots, Dr. Semmulweis noted that the male doctors and medical students were doing autopsies while the midwifes were not, and that “cadaverous particles” (this is a period of time before germs were known) were being spread to those birthing mothers.

Dr. Semmulweis’ medical innovation? “Wash your hands!” The net result, after doctors and midwifes started washing their hands (in lime water, then later in chlorine), was that the rate of childbed fever dropped considerably.

Now, if you’re in the medical trade, washing your hands multiple times per day in chlorine or (by the late 1800’s) carbolic acid, you’ll note that it isn’t so good for your skin or hands.

In 1890 William Stewart Halsted of Johns Hopkins University asked the Goodyear Tire and Rubber Company if they could make a glove of rubber that could be dipped in carbolic acid in order to protect the hands of his nurses – and so was born the first sterilized medial gloves. The first disposable latex medical gloves were manufactured by Ansell and didn’t appear until 1964.

What does this foray in to 19^th century medical history mean for Internet security I hear you say? Simple really, every time the end user needs to use a computer to access the Internet and do work, it needs to be clean/pristine. Whether that means a clean new virtual image (e.g. “wash your hands”) or a disposable environment that sits on top of the core OS and authorized application base (e.g. “disposable gloves”), the assumption needs to be that nothing the user encounters over the Internet can persist on the device they’re using after they’ve finished their particular actions.

This obviously isn’t a solution for every class of cyber threat out there, but it’s an 80% solution – just as washing your hands and wearing disposable gloves as a triage nurse isn’t going to protect you (or your patient) from every post-surgery ailment.

Operating system providers or security vendors that can seamlessly adopt and automatically procure a clean and pristine environment for the end user every time they need to conduct activities on or related to the Internet will fundamentally change the security game – altering the battle field for attackers and the tools of their trade.

Exciting times ahead.

-- Gunter

The Incredible Value of Passive DNS Data

If a scholar was to look back upon the history of the Internet in 50 years’ time, they’d likely be able to construct an evolutionary timeline based upon threats and countermeasures relatively easily. Having transitioned through the ages of malware, phishing, and APT’s, and the countermeasures of firewalls, anti-spam, and intrusion detection, I’m guessing those future historians would refer to the current evolutionary period as that of “mega breaches” (from a threat perspective) and “data feeds”.

Today, anyone can go out and select from a near infinite number of data feeds that run the gamut from malware hashes and phishing URL’s, through to botnet C&C channels and fast-flux IPs. 

Whether you want live feeds, historical data, bulk data, or just API’s you can hook in and ad hoc query, more than one person or organization appears to be offering it somewhere on the Internet; for free or as a premium service.

In many ways security feeds are like water. They’re available almost everywhere if take the time to look, however their usefulness, cleanliness, volume, and ease of acquiring, may vary considerably. Hence there value is dependent upon the source and the acquirees needs. Even then, pure spring water may be free from the local stream, or come bottled and be more expensive than a coffee at Starbucks.

At this juncture in history the security industry is still trying to figure out how to really take advantage of the growing array of data feeds. Vendors and enterprises like to throw around the term “intelligence feeds” and “threat analytics” as a means of differentiating their data feeds from competitors after they have processed multiple lists and data sources to (essentially) remove stuff – just like filtering water and reducing the mineral count – increasing the price and “value”.

Although we’re likely still a half-decade away from living in a world were “actionable intelligence” is the norm (where data feeds have evolved beyond disparate lists and amalgamations of data points into real-time sentry systems that proactively drive security decision making), there exist some important data feeds that add new and valuable dimensions to other bulk data feeds; providing the stepping stones to lofty actionable security goals.

From my perspective, the most important additive feed in progressing towards actionable intelligence is Passive DNS data (pDNS).

For those readers unfamiliar with pDNS, it is traditionally a database containing data related to successful DNS resolutions – typically harvested from just below the recursive or caching DNS server.

Whenever your laptop or computer wants to find out the IP address of a domain name your local DNS agent will delegate that resolution to a nominated recursive DNS server (listed in your TCP/IP configuration settings) which will either supply an answer it already knows (e.g. a cached answer) or in-turn will attempt to locate a nameserver that does know the domain name and can return an authoritative answer from that source.

By retaining all the domain name resolution data and collecting from a wide variety of sources for a prolonged period of time, you end up with a pDNS database capable of answering questions such as “where did this domain name point to in the past?”, “what domain names point to a given IP address?”, “what domain names are known by a nameserver?”, “what subdomains exist below a given domain name?”, and “what IP addresses will a domain or subdomain resolve to around the world?”.

pDNS, by itself, is very useful, but when used in conjunction with other data feeds its contributions towards actionable intelligence may be akin to turning water in to wine.

For example, a streaming data feed of suspicious or confirmed malicious URL’s (extracted from captured spam and phishing email sources) can provide insight as to whether the customers of a company or its brands have been targeted by attackers. However, because email delivery is asynchronous, a real-time feed does not necessarily translate to current window of visibility on the threat. By including pDNS in to the processing of this class of threat feed it is possible to identify both the current and past states of the malicious URL’s and to cluster together previous campaigns by the attackers – thereby allowing an organization to prioritize efforts on current threats and optimize responses.

While pDNS is an incredibly useful tool and intelligence aid, it is critical that users understand that acquiring and building a useful pDNS DB isn’t easy and, as with all data feeds, results are heavily dependent upon the quality of the sources. In addition, because historical and geographical observations are key, the longer the pDNS data goes back (ideally 3+ years) and the more data the sources cover global ISPs (ideally a few dozen tier-1 operators), the more reliable and useful the data will be. So select your provider carefully – this isn’t something you ordinarily build yourself (although you can contribute to a bigger collector if you wish).

If you’re looking for more ideas on how to use DNS data as a source and aid to intelligence services and even threat attribution, you can find a walk-through of techniques I’ve presented or discussed in the past here and here.

-- Gunter

Breaking out of the consulting wave

There are certain thresholds in the life of a company that must be crossed and, in so doing, fundamentally alter the business. In the world of boutique security consulting companies, one such period of change (and resultant growth) is when the task of managing client relationships and securing the next project or client shifts from being part of a senior consultant’s role and transitions in to the waiting hands of a dedicated sales organization.

Over the years I’ve observed first-hand just how difficult this transition can be for both the senior consultants and the executive management.

A critical driver for this transition is the way consultants are forced to divide their time and attention. When the consultant isn’t on a paid engagement they spend time responding to clients and prospects – writing proposals, responding to RFI’s, and scoping engagements etc. When they’re working on a client project, it’s heads-down on delivery – meaning that there’s far less time to engage with other customers or prospects, and limited attention can be applied to lining up the next consulting job. Visually, the cyclical nature of this business mode resembles a graph of out-of-phase waveforms transposed upon one-another.

If the red line represents the effort the consultant applies to “project delivery” over time, and the blue line in turn represents “business development”, it should be clear that low periods of non-delivery are countered with high periods of hunting for new work, and vice versa.

The problem with this cyclical work pattern is that a company typically only makes money if the consulting is delivering on paid engagements – and ideally you’d want the red-line to be horizontal and as close to 100% delivery utilization as possible.

If that wasn’t already an obvious problem, its effect on the business is then multiplied – as the task of securing business and constructing new proposals typically falls upon the most senior consultants. This in turn means that the most expensive people in the consulting organization, who typically command the highest rates from clients, are the most absorbed in this perpetual sales-delivery cycle.

I’ve heard time and again that “it’s just the way it is” and arguments such as:

• As a technical consultancy, the client demands that they deal directly with the technical manager doing the delivery.
• Scoping a job and preparing a technical proposal requires an expert consultant.
• The onsite consultants know the customer the best. They’re always doing jobs for the client.
• Our consultants are managing consultants, and that’s what they do.

The list of “why things can’t change” could go on ad infinitum, but the reality is that a consulting company cannot grow and scale beyond its senior consultants until it breaks out of the cyclical pattern – which is why this particular threshold is both so important and difficult for a company to transition.

Some things I’ve learnt over the years in navigating this business transition (and hopefully serve as some useful advice to other businesses seeking to cross the threshold) include:

• The best security consultants, no matter how much they think of their skills at procuring and securing new business, are at best average farmers of an account (compared to a dedicated sales person). Yes, they typically understand the clients they do regular work for and are proficient at recognizing other opportunities within that client organization – however that pursuit and business development is limited to the client personnel they actually interact with during an engagement. The net result is that the client’s technical on-site folks love and adore the consultant and company, but most engagements are limited to a silo within the overall organization. For this reason the consulting company needs “hunters” – folks with the business development experience to identify other new people and opportunities in other parts of the same business.
• Dropping in a “sales guy” in to the organization and letting them figure it out because they have a track record selling things is unlikely to succeed. Security consulting (in particular) is a very technical sell, and those tasked with hunting and closing in on new clients and projects need to not only also be technical, but need to be backed by deeper technical expertise. Consider the physical differences between an Olympic high-jumper and an Olympic shot-putter. Both sports require unique attributes, and are unlikely to triumph in the others field of expertise. While an Olympic decathlon medalist may be able to do both, they’re also unlikely to win against someone who specialized in just one of those sports.
• Consulting managers are not sales people, they’re delivery coordinators and quality evangelists. Their role is often inglorious – as in-between chasing consultants for expenses and report deliverables, they spend much of their time apologizing to the client for things that didn’t go quite to plan and making the client happy again. Yes, they’re often the front line with existing customers and are core to delivering proposals to new clients, but their business development focus is (and should remain) blinkered to delivery.
• In many cases the role of a consulting manager can morph in to that of a sales engineer (just never call them that!). When a consulting manager has no direct reports, they can serve effectively as the technical backup to the sales team – scoping engagements, constructing technical proposals, and being the technical evangelist is new client and prospect meetings. This “sales engineer” (SE) role is often a critical component to building and supporting a successful consulting sales team. The stronger these technical experts are, and the more years under the belt consulting they have, the more respect they tend to garner from prospective clients, and the easier it is to close deals. In many ways they add the technical credibility to the sale organization for technical clients.
• Plan on building out a central team of technical authors. The technical author team provides the grease for easing a company through the transition period. By (slowly) removing some of the tedious consulting work – i.e. proposal generation, report proofing, and quality assurance on deliverables – the technical author team ensures a consistent quality of client-facing materials and eases the burden on the consulting and sales teams, and further frees up the time of valuable consultants. For global consulting companies or businesses that have consultants scattered around the world, the technical authorship team also helps overcome second-language frailties. Some caution needs to be maintained as these teams can be quickly overwhelmed with high workloads – which is why they should ideally report in to a senior consulting manager.
• Senior and managing consultants who have been “managing accounts” often have compensation plans linked to closing client deals. The incorporation of a dedicated sales team means that compensation plans need to be reevaluated for those consultants. Ideally this type of conversation happens prior to the hiring and buildout of a sales team – and that the consultants concerned are party to how the transition will occur and how compensation can be changed. Since the monies associated with managing an account are not often insignificant, it is vital that those consultants are offered alternative means of “making their number”. Luckily the company has several tools at their disposal. First of all, since the purpose of employing a dedicated sales team is to grow revenue and increase the billable hours of senior consultants, there is typically scope to increase the base salaries of those consultants and to create a bonus payment structure based upon utilization and customer satisfaction levels. Alternatively, that important role conversion in to a consulting manager (i.e. SE) can be useful in a hybrid compensation model, where factors such as new clients versus lateral growth in an existing client are bonused differently.

The business transformation from 100% consultants to a mix of consultants and dedicated sales personnel can be perilous if not managed carefully. The senior consultants need to be well informed and actively participate in the transition, and the sales team built gradually from a nucleus of experienced sales professionals that have come from consulting businesses that had already successfully transitioned.

Any transition will take time. The senior consultants in particular must be gradually weaned off their account management responsibilities, and replaced with ones that drive a higher utilization rate for them and any other consultants they may lead. The worst thing a leadership team can do is to expect the transition to happen overnight. Instead, they should anticipate the process being a 3-9 month transition; the end result is worth it though.

Hacker Hat-trick at TalkTalk

For the third time this year the UK broadband provider TalkTalk have seen their online defenses fall to cyber attackers.

While the company has been quick to notify their customers of the breach (it was observed on Wednesday this week and reported the following day) and are currently working with law enforcement, details are still relatively sparse. Given the very short period between detection of the attack and public notification, it is unlikely any significant cyber forensics exercise has been conducted… so it’ll likely take those tasked with the investigation a couple of weeks to get a solid understanding of the scope of the breach and what was likely touched or stolen by the attackers.

Regardless, the stories currently being published as to the nature of the breach and what has actually been stolen are confusing and the details often contradictory (see Business Insider, The Telegraph, BBC, and AOL). It would appear that the names, addresses, dates of birth, email addresses, telephone numbers, TalkTalk account information, and credit card and/or bank details of some 4,000,000 subscribers may have been stolen and that the data may not have been (completely?) encrypted… or maybe the encryption keys were similarly stolen.

Claim for the latest hack are also being attributed by some to a Russian Islamist group (referred to as the “Th3 W3b 0f H4r4m”) who has posted a claim online along with samples of the data purporting to have come from the TalkTalk site (see Pastebin - http://pastebin.com/HHT4BxJA).

Some stories refer to there being a DDoS attack or component. A DDoS attack isn’t going to breach an internet service and result in data theft, but it’s not unheard of for attackers to use such a mechanism to divert security teams and investigative resources while a more focused and targeted attack is conducted. It’ll be interesting to see if this actually happened, or whether the DDoS (if there was one) was unrelated… although it would be difficult to tell unless the attackers really messed up and left a trail of breadcrumbs – since DDoS services can be procured easily over the Internet for as little as $50 per hour from dozens of illicit (but professional) providers.

If there are lessons to be learned so far from this hat-trick breach, they include:

• Hackers are constantly looking for easy prey. If you’re easy pickings and you get a reputation for being a soft target, you should anticipate being targeted and breached multiple times and likely by different attackers.
• There should be no excuse for not carefully encrypting customer data, and using cryptographic techniques that make it impractical for attackers that do breach an organizations defenses to profit from the encrypted data they stole.
• Calling an attacker or the tools they use “sophisticated” and expecting the victims of the breach to consul themselves with the knowledge that the organization charged with protecting their data was defeated by a supposedly more advanced adversary is wrong. It simply underlines a failure to understand your adversaries and invest in the appropriate security strategies.

-- Gunter Ollmann

Ambulance Chasing vs Neighborly Support

The evolving world of Internet Security has a tendency to be a complex and bemusing arena for the professionals that make their living from it. The rapid development and deployment of immature technologies, the growing size and sophistication of systems, the unwanted attention and migration of organization crime, and the near religious fervor some devote to the ethical quandaries of the Internet, mean that few security topics are neither simple or devoid of opinion.

One area of topic guaranteed to crop up in a weekly discussion of Internet security is the topic of “ambulance chasing”. It’s a topic capable of dividing a room; initiating a prompt and well-rehearsed ethics debate, and causing more than a few veins on people’s foreheads to swell and pulsate.

Now that breach disclosures are a daily occurrence and the frequency of “mega breaches” seem to have hit their stride of monthly broadcasts, much of the security industry really does need to put on its big-boy pants and overcome the philosophical debate of whether reaching out to a breach victim and offering to work with them to understand, overcome, mitigate, or remediate, is in fact “ambulance chasing” or more akin to being neighborly and professional.

For many folks, the prospect of contacting a victim and explaining what you could do to help them evokes a vision of seedy lawyers prowling the halls of hospitals looking for the latest motor accident patients.

The vast majority of security professionals I know (ranging from consultants to analysts, and sales to engineers) genuinely see their occupation as a calling and passionately want to help make the Internet a better place. However, for one reason or another, the prospect of reaching out to someone that hasn’t already reached out to them and explicitly asked for help is too often interpreted as a breach of some unwritten rule… a kind of “invasion of personal space”.

For sure, as a professional they’re offering your skills and expertise for a price. However, to interpret the actions of pro-actively reaching out to a victim as some slimy underhanded means of gaining business is naive and outdated. Amusingly enough, the majority of security consultants I’ve known or worked with other the years are only too capable of identifying new victims that they or their company could help, but may grudgingly to pass it on to a “sales guy” – thereby keeping their hands clean and distancing themselves from what they perceive as ambulance chasing sleaziness.

I don’t see it that way and as advice to consultants that want to grow their career and move on to becoming business leaders (with the reputation and salary to go with it), get over your inhibitions and reach out to those organizations and contacts yourself. Forget the term “ambulance chasing” and instead think in terms of supporting a neighbor down the road.

Look at it this way. You’re an expert locksmith. Every day you walk your dog down the street and you notice how poor many of the locks are (and how many are missing). Then one day a house down the street is burgled. You see the flashing lights outside, police dusting for fingerprints, and a substandard lock was clearly dismantled and exploited by the criminal to gain entry. Do you ignore the incident and hope the victim will Google locksmiths later and contact you, or do you rush home to make a call to your sales guy and tell them your neighbors address and leave it in their hands? Or, as a professional confident in your skills and expertise, approach the victim, introduce yourself and what you do, and offer to help them if and when they’re ready?

Think about it from the perspective of the victim too. Would you rather hunt and peck looking for someone to help? Would you prefer a sales guy cold calling you and pimping all their products? Or would you respond most favorably to a local expert from down the street who approaches you directly and offers to help there and then?

In a world of daily breaches and vulnerability disclosures, more people need help than ever before. As a security professional, if you’re waiting for them to reach out to you and ask for your help, you’re doing a disservice to both them and yourself. 

Experian Breached; T-Mobile Customer's Loss

The last couple of days has seen yet another breach disclosure - this time it's Experian, and the primary victims are 15m T-Mobile customers in the US. It was interesting to note T-Mobile's CEO, John Legere, publicly responding to the breach and the effect on his customers. He's angry, and rightfully so. I'm sure there are a bunch of other credit bureaus now lining up to secure new business.

Some personal thoughts on the breach and it's effects:

• As is so often the trend now, professional hackers and cybercriminals are investing in the long game – stealthily taking control of a network and the data it contains over weeks, months and even years. Instead of opportunistic zero-day exploitation against lists of potential vulnerable targets, hackers carefully probe, infiltrate, and remove evidence of compromise against specific targets. Their end game is perpetual access to the target. The difference is as stark as killing the cow for today’s BBQ, or silently milking it for years.
• While many organizations now employ encryption and cryptographic techniques to protect personal customer data. Many of the techniques employed are dated and focus predominantly on a mix of data-at-rest protection (to combat theft of hard drives or backup cassettes) and SQL DB data dumps – threats that, while severe, are not common targets of prolonged infiltration and stealthy attackers. A critical failure of many of these legacy approaches to data encryption lies in key management. Access to the keys used to encrypt and decrypt the data is a primary target of todays hackers. Unfortunately organizations have great trouble finding secure methods of protecting those keys and still often operate at a level of obfuscation equivalent to leaving the keys under the doormat.
• The data stolen in this attack on Experian’s T-Mobile customers – which includes address details, date of birth, social security numbers, driver license numbers, and maybe passport numbers – is very valuable to cybercriminals. These aggregated personal details can reach as much as $200 per record on various underground forums and locations in the darknet. Stolen identities that include address, SSN, and drivers license details are commonly used in the creation of new online financial accounts – as the professional cybercriminals seek to launder other stolen monies from around the world.
• Constant vigilance is mandatory when it comes to combating professional cybercrime who are in for the long game. It is critically important that organizations continually probe, assess, and monitor all Internet accessible services and assets. Annual penetration testing and quarterly scans didn’t work against this class of threat a decade ago, they most certainly provide less protection and assurance today. Organizations need to be vulnerability scanning their web applications and infrastructure continuously on a 24x7 timetable, must deploy breach detection systems that monitor network and egress traffic, and practice incident response on a monthly basis.

I'm sure that new details will filter out over coming weeks and, if history is anything to go by, the odds are that the victim count will continue to grow.

-- Gunter