Research

As we wrap up our series on secure networking in the cloud era, we have covered the requirements and migration considerations for this new network architecture – highlighting increased flexibility for configuration, scaling, and security services. In a technology environment which can change as quickly as a developer hitting ‘commit’ for a new feature, infrastructure needs to keep pace, and that is not something most enterprises can or should build themselves. One of the cornerstones of this approach to building networks is considering the specific requirements of the site, users, and applications, when deciding whether to buy or build the underlying network. This post will work through a few use cases to highlight the power of this approach, including: Compromised Remote Device: The underlying network supporting cloud computing needs to respond, pretty much instantaneously when under attack. This use case will show how you can protect it network from users who appear to be compromised, without needing someone at a keyboard reconfiguring pipes. Optimized Interconnectivity: You might have 85 stores which need to be interconnected, or possibly 2,000 employees in the field. Or maybe 10 times that. Either way, provisioning a secure network for your entire organization can be highly challenging – not least because mobile employees and smaller sites need robust access and strong security, but fixed routes can negatively impact network latency and performance. Protecting SaaS: Cloud applications have become a visibility black hole for enterprises, so we’ll discuss how to protect users and sites which access critical corporate data, even if they never traverse a traditional corporate network. This is especially important because the lack of clear inspection points on the network breaks traditional security models, so you need to bring the secure network to the site and/or users. Security by Constituency: One of our key requirements is the ability to flexibly support users, locations, and applications; so our final use case will show how a policy-driven software-defined secure network can provide the secure connectivity required by a variety of different users. Of course there is considerable overlap between these use cases. For instance a mobile employee may predominately use SaaS applications, thus benefit from both those use cases. But these scenarios help illuminate the future of secure networking. Compromised Remote Device It happens on your network all the time. A device is compromised and starts acting strangely. One of your security monitors fires an alert, which shows suspicious activity from that device. In the old days you needed to figure out whether the issue was real; then go into the network console, isolate the device, and begin investigation. It all sounds simple enough, right? But what happens when the device is remote, and not on your corporate network? You might not know the device has been compromised, and you may have no way to take it off the network. Hopefully it won’t slip buy long enough to escalate privileges and find a way into your internal network. To address this, you basically extend your network out to your users. So the device connects to the closest point of presence (regardless of where it is) and virtually joins your corporate network. Sure, that sounds a lot like just running each user on a VPN and bringing them back behind your perimeter, but this model offers real advantages. First, traffic is not backhauled to your corporate network, which avoids overburdening the security controls and adding a huge amount of latency. The burden of enforcing security polices happens within the network, not on the devices running on your premises. Second, compromised devices are isolated from the rest of your network. It becomes much harder for attackers to move laterally through your network, because they need to bypass additional inspection points to reach the internal network. Once a device has been determined to be compromised, a policy can automatically quarantine it to prevent access to key SaaS apps and the internal network. Optimized Interconnectivity One of the larger hassles in networking is supporting large numbers of remote sites. Setting up many security devices, especially remotely, both costs and requires onsite IT chops to troubleshoot. And of course traveling employees are all over the place, demanding fully access to critical data (both on the internal network and in the cloud), as if they were in the office. These are two separate issues, but there is one solution. It involves extending the secure network to the user and/or site. This enables you to use a last-mile service, typically a basic dumb Internet pipe, for access to the closest point of presence with access to your network. Once on your network, the user or site gets all the same intelligent routing and security services as on your corporate network. Without having to backhaul traffic to your corporate network. Of course you need to figure out whether to build out PoPs and network infrastructure to extend the network where your organization needs it. In reality, you are likely to engage a network service provider to build a virtual network between your sites, and provide connectivity to your users. This gets you out of the Wide Area Networking business. In many scenarios it provides enhanced network performance, increased security, and greater flexibility. We won’t weigh in on cost because many factors affect the cost of provisioning this kind of network, but the additional capabilities make this a pretty easy decision if the costs are in the ballpark. Protecting SaaS As we mentioned previously, the advent of SaaS has removed much of your visibility into what employees are doing in critical applications. Let’s consider a sales automation service and a disgruntled salesperson who wants to grab his client list before quitting. If they are sitting in a coffee shop somewhere, you probably have no idea what they are doing within the application, because they don’t traverse your network to access the SaaS service. But if you have the rep on a performance plan, you know they are a flight risk. So you can proactively set a

As we noted in our introductory post for this Network Security in the Cloud Age series, everything changes, and technology is undergoing the most radical change and disruption since… well, ever. We’re not kidding – check out our Tidal Forces post for the rundown. This disruption will have significant ramifications for how we build and manage networks. Let’s work through the requirements for this network of the future, and then provide some perspective on how you can and should migrate to the new network architecture. At the highest level, the main distinction in building networks in the Cloud Age is moving from a one to many network(s) model. Networks have been traditionally been built and managed as a single enterprise network, which required these environments to be built for peak usage, but at the same time to support the lowest common denominator from a functionality standpoint. Yes, those are contradictory requirements – that’s how it worked out. Your network had to serve all masters (regardless of the disparity in functional requirements per application) and be sized to stay up under any conceivable load. In the Cloud Age we need to think differently. Now it’s about what kind of network this specific application or use case requires not what you already have. So you build what is needed, where it’s needed. We’ll get into specific use cases later in this series, but a network to support a distributed workforce doesn’t need, and probably shouldn’t have, the same characteristics of the network that interconnects your primary sites. And an externally-facing web application needs a different network than one for access to sensitive data still locked within your enterprise data center. And everything in the Cloud Age is software defined. You basically program your network, adapting it to specific conditions laid out in a set of governing policies. No more crawling around the wiring closet to find the faulty cable that knocked out your G/L system. Though we’re sure you’ll miss those days. Cloud Age Secure Network Requirements When we translate the hand-waving above into specific requirements for a secure network of the future, we come up with the following: Availability: This is consistent with the networks you have been building for decades. It’s a bad day for the network/security team when the network goes down, whether in your data center or the cloud. So a cloud network needs to be built to ensure availability with diverse routes, alternative access points, and alternative access to corporate date – wherever it may reside. Elasticity: Instead of building a network for peak usage, you don’t need to really do anything here. Ensuring sufficient bandwidth is the cloud provider’s problem, not yours. Obviously if you use more you pay for more (metered billing), but you don’t need to put in a big order for new mega switches which might be fully utilized once over the next year. You just need to make sure the provider can scale to what you may need, and that you can expand and extend your network as needed. Software Defined: The cloud demands flexibility. A cloud network needs access flexibility because employees and other constituents move around. It needs architectural flexibility – you will need to adapt to changing requirements in areas such as scaling, usage, and security. Things move very quickly in cloud land, and you don’t have time to wait for network administrators to reconfigure the network, so you need an automated system to do it. This is driven by software, so orchestration and automation via other products and services is essential. Policy-driven: Speaking of Software Defined Networks (SDN), you need a cloud network governed by policies which specify rules for when it changes. Many attributes can drive these policies, and the role of a network security architect is evolving to encompass these policies, because once released into production policies are applied automatically and immediately, so things can go south quickly if they aren’t solid. Flexibly Secure: Finally, you want to make sure all your constituencies can be supported and protected by the cloud network. So if you support remote users proper authentication, access control, and inspection for threat/malware detection must be provided on the ingress side. You’d also like those users’ egress traffic (including encrypted traffic) to be protected against security issues, such as data leakage and connections to malicious servers. Additionally, you should be able to protect traffic to cloud applications. And cloud networks needs to satisfy all these use cases. Monitoring & Reporting: Compliance oversight and governance don’t go away when you move to the cloud. So you need visibility into the network traffic to detect performance and security issues, as well as the ability to generate reports to substantiate network activity and security controls. Migration A good thing about moving to secure networks in the cloud age is that you don’t need to get there in one fell swoop. It’s not like an overnight cutover to a new switching environment because the old and new vendors cannot play nicely together. This is where moving from one monolithic network to many application-specific networks pays huge dividends. You can keep running your existing enterprise network to support the functions still served out of your own data centers. If your web app and manufacturing systems run on your own hardware, moving that data to the cloud probably doesn’t make sense. But as you move or rebuild those applications within a public cloud environment or embrace Software as a Service (SaaS) to replace legacy applications, you can move that traffic to a cloud network. You may be able to take better advantage of your WAN by leveraging a service provider. Supporting access for a global user base, and maintaining connections between sites, may not be the best use of your constrained networking and security resources. The other area to focus on is the back-end interconnection points between your existing enterprise networks and cloud services. This is where you are most exposed, because any issues in your data center could

We are pleased to launch our latest research paper, on Docker security: Assembling a Container Security Program. Containers are now such integral elements of software delivery that enterprises are demanding security in and around containers. And it’s no coincidence that Docker has recently added a variety of security capabilities to its offerings, but they are only a small subset of what customers need. During our research we learned many things, including that: Containers are no longer a hypothetical topic for discussion among security practitioners. Today Development and Operations teams need a handle on what is being done, and how to verify that security controls are in place. Security attention in this area is still focused on OS hardening. This is complex and can be difficult to manage, but it is a fairly well-understood set of problems. But there are many more important moving pieces in play, which are still largely being ignored. Very little attention is being paid to the build environment – making sure the container contains what it should, and nothing else. The companies we talked to do not, as a rule, verify that internal code and third-party libraries are secure. Human error is more likely to cause issues than security bugs. Running services in the container with root credentials, poor handling of keys and certificates, opening up ports inappropriately, and indiscriminate communications are all common issues… which can be tested for. The handoff from Development to Operations, and how Operations teams vet containers prior to putting them into production, are somewhat free-form. As more containers are delivered faster, especially with continuous integration and DevOps engineering, container management in general – and specifically knowing what containers should be running at any given time – is becoming harder. Overall, there are many issues beyond OS hardening and patching your Docker runtime. Crucial runtime aspects of container security include monitoring, container segregation, and blocking unwanted communications; these are not getting sufficient attention. They ways containers are built, managed, and deployed are all important aspects of application security, and so should be core to any container security program. So we took an unusually broad view of container security, covering each of these aspects in this paper. Finally, we would like to thank Aqua Security for licensing this content. Community support like this enables us to bring independent analysis and research to you free of charge. We don’t even require registration. You can grab a copy of the research paper directly, or visit the paper’s landing page in our research library, and please visit Aqua Security if you would like to understand how they help provide container security. Share:

Imagine a black hole suddenly appearing in the solar system – gravity instantly warping space and time in our celestial neighborhood, inexorably drawing in all matter. Closer objects are affected more strongly, with the closest whipping past the event horizon and disappearing from the observable universe. Farther objects are pulled in more slowly, but still inescapably. As they come closer to the disturbance, the gravitational field warping space exponentially, closer points are pulled away from trailing edges, potentially ripping entire planets apart. These are tidal forces. The same force that creates tides and waves in our ocean, as the moon pulls more strongly on closer water, and less on seas on the far side of the planet. Black holes are a useful metaphor for disruptive innovations. Once one appears it affects everything around it, and nothing looks the same at the end. And like a black hole’s gravity, business/technical tidal forces rip apart our conceptions, markets, and practices – slowly at first, accelerating as we approach an event horizon, beyond which the future is unclear. I have talked a lot about disruptive innovation over the past nine years, since starting Securosis. In blog posts, on stage at RSA (with Chris Hoff), and in countless other venues. All my research continues to convince me we are deep into a series of shifts, which are shredding existing security practices and markets, at a much deeper and more fundamental level than we have seen before. This is largely because now is the the first time we have had a profession and markets large enough for these forces to act on in a meaningful way. If a market falls down in the woods, and there aren’t any billion-dollar companies to smash on the head, nobody pays attention. Now our magnitude and inertia magnify these disruptions. Sticking with my metaphor, I like to think of these disruptive forces as three black holes influencing all information technology. Security is only one of the many areas impacted, but it is the only one I am really qualified to discuss. There are also a series of other emergent waves and interactions which complicate the model and could fill a book, but I’ll do my best to focus on the most impactful trends. As I lay these out, please keep in mind that I am not saying these eliminate security issues – but they definitely transform them. Endpoints are different, often more secure, and frequently less open: The modern definition of an ‘endpoint’ is almost unrecognizably different than ten years ago. Laptop and desktop sales are stagnant, as phones put more power into your pocket than a high-end desktop had when this shift started. Mobile devices are incredibly secure compared to previous computing platforms (largely due to their closed systems), while modern general purpose computer operating systems are also far more hardened (and compromised less often) than in the past. Not perfect – but much better, with a higher exploitation cost, and continuously improving. Ask any enterprise security manager how Windows 7-10 infection rates look compared to XP, entirely aside from the almost complete lack of widespread malware on Apple’s iOS and macOS. But these devices are not only largely inaccessible to many security vendors (notably monitoring and anti-malware), but their tools don’t offer much value for preventing exploitation. Combined across consumer and enterprise markets, these trends have produced a major consumer shift to phones and tablets. In turn, this has slenderized the cash cow of consumer (and often enterprise) antivirus, with clear signs that evem on traditional computers, the mandatory security footprint will shrink in time. The ancillary effects on network security are also profound – we will address them in a moment. Even the biggest fly in the ointment, the massive security issues of IoT, are poor fits for ‘traditional’ tools and practices. Software as a Service (SaaS) is the new back office: Email, file servers, CRM, ERP, and many other back-office applications are rapidly migrating from traditional on-premise infrastructure into cloud services. Entire fleets of servers, which we have dedicate massive budgets to securing, are being shut down and repurposed or decommissioned. Migrating these to a mature cloud service often reduces security risk and cost. On the other hand moving to less secure SaaS providers (most of the market) requires a compensatory shift in security operations, skills, and spending. This transition also supports the rise of zero trust networks, where enterprises no longer trust their local networks, instead requiring all connections to all services to be encrypted with TLS (increasingly immune to existing monitoring techniques) or VPN. Between this transition to the cloud and the growth in encrypted connections, we see dramatic impacts to perimeter security, monitoring, patching, incident response, and probably a dozen other security practices. Migrating to highly secure cloud services wipes out the need for large portions of existing security, and the corresponding increases are much smaller, producing an often substantial net gain. Worst case, you might still deploy your own software stack, but it will be in an IaaS cloud instead of a data center across the corporate campus. Infrastructure as a Service (IaaS) is the new data center: Major cloud providers (a very short list of very large companies) offer infrastructure which, thanks to economic forces, is far more secure than most enterprise data centers. Amazon Web Services itself was about a $12B business in 2016, so clearly the migration to cloud computing is now more of a stampede. A shift merely from physical to virtual machines would still be important, with wide-ranging impact, but we are watching a deeper architectural transformation, driven by cloud providers’ software defined networks; combined with serverless, containers, and other emerging options. You cannot stick your existing IPS in front of a Lambda function, nor can you patch or configure an Elastic Load Balancer. Many foundational security practices, which we rely on to protect our custom applications, either aren’t needed or cannot be implemented using traditional tools or techniques. All of this is available when build

We have spent a lot of time discussing the disruptive impact of the cloud and mobility on… pretty much everything. If you need a reminder, check out our Inflection paper, which lays out how we (correctly, in hindsight) saw the coming tectonic shifts in the computing landscape. Rich is updating that research now, so you can check out his first post, where he discusses the trends which threaten promise to upend everything we know about security: Tidal Forces. To summarize, cloud computing and mobility disrupt the status quo by abstracting and automating huge portions of technology infrastructure – basically replacing corporate data centers in many cases. You no longer stroll down to the wiring closet to troubleshoot network problems, because your employees are distributed across the world, using all sorts of devices to access critical data. Your data center may no longer exist, but it is certainly much less important and valuable today, because it has been replaced to some degree by a monstrous Infrastructure as a Service (IaaS) provider who offers far better economies and much faster turnaround than your IT group ever could. The physical layer is totally abstracted, and you interact with your network (and the rest of your technology stack) through a web console – or more likely, an API. Development and Operations organizations are now collaborating, which means as soon as a developer makes a change it can be immediately deployed (after some automated testing) to the production environment. Continuous deployment may require network changes, and can introduce security issues. But there isn’t really any ability to have a human scrutinize all the changes, or ensure all the governance and security policies are in place and effective. To further complicate things, you no longer run many applications on infrastructure you control. In case you haven’t heard, Software as a Service (SaaS) is now a thing (we call it “the new back office”), and you don’t get to tell a SaaS provider what their network should look like. You connect to their service over the Internet, and that’s that. You no longer know where your data is, nor do you have the ability to monitor traffic flows for misuse. To be a bit clearer about the impact on networking in the cloud age, let’s highlight the impacts: Your data is everywhere (and nowhere): Whether it’s an application you built (now running in an IaaS environment) or an application you bought (provided by a SaaS vendor), either way you no longer have any idea where your data is, and limited means to protect it on the network. Lack of visibility: You cannot tap an IaaS or SaaS environment, so you don’t have visibility into what’s happening on your network. Some cloud providers are offering increasing access to network telemetry, but raw packet access is a poor fit for the cloud’s agility and elasticity. Bottlenecks don’t make sense: One way to get around the lack of visibility is to route all traffic through an inspection point, and enforce security policies there. Unfortunately most cloud-native architectures don’t support that approach, due to the inherent isolation between computing tiers, and the increasingly popularity of serverless systems. The last thing you want to do is make the cloud look just like your existing environment, so traditional bottlenecks won’t survive this disruption. App-specific infrastructure: Finally, you don’t just have one network to worry about. You can have hundreds if you implement every IaaS stack as its own network(s). Every SaaS service you buy runs on its own network. There is no longer any consistency between cloud application networks. Overall this is an improvement, because each application can have its own network – designed, tuned, and sized to its particular requirements. Applications are no longer forced into a one-size-fits all suboptimal network, but they also aren’t forced onto your network, with all your integrated security requirements and capabilities. Velocity of change is unprecedented: With continuous deployment changes to the network need to happen in lock-step with application and operational changes. This means your network and security ops folks’ work queues are going the way of the Dodo bird. There just isn’t time for traditional network management and security, and your existing staff cannot keep pace in this kind of environment. The tidal forces of the cloud are rapidly upending almost everything you know about security. Those who fail to get their arms around this, clinging doggedly to old models, will fail. Focusing on the Right Things Before you reach for the hemlock, let’s take a step back to remember what we really need to provide as network security professionals: Connectivity: The network needs to provide access to resources (applications and data) wherever in the world they reside, whenever users they need access, on whatever device they happen to be using. Within policy constraints of course, but IT can no longer simply dictate access terms. Availability: The network needs to be reliable and survivable to satisfy application uptime requirements. It is a bad day when business stops because of a network problem, and worse when a security issue takes the network down. Performance: There are many potential choke-points which can slow down an application. But the network should not be one of them – even during peak usage. In the old days you needed to design and build for peak usage. But you got no credit for the other 99% of the time, when some (perhaps most) of that infrastructure was idle. Security: Last but not least, you had better not have any security issues originating from the network. Instead the expectation is that you will detect attacks using the network. So you need to make sure the network is secure, rather than a vector for attack. The cloud can help us satisfy each of these critical imperatives. But: not if you think you can get away with the same old, same old, running all your traffic through a small set of ingress and egress points to inspect traffic using your old security equipment.

As we wind down the year it’s time to return to forward-looking research, specifically a concept we know will be more important in 2017. As described in the first post of our Dynamic Security Assessment series, there are clear limitations to current security testing mechanisms. But before we start talking about solutions we should lay out the requirements for our vision of dynamic security assessment. Ongoing: Infrastructure is dynamic, so point-in-time testing cannot be sufficient. That’s one of the key issues with traditional vulnerability testing: a point-in-time assessment can be obsolete before the report hits your inbox. Current: Every organization faces fast-moving and innovative adversaries, leveraging ever-changing attack tactics and techniques. So to provide relevant and actionable findings, a testing environment must be up-to-date and factor in new tactics. Non-disruptive: The old security testing adage of do no harm still holds. Assessment functions must take down systems or hamper operations in any way. Automated: No security organization (that we know of, at least) has enough people, so expecting them to constantly assess the environment isn’t realistic. To make sustained assessment feasible, it needs to be mostly automated. Evaluate Alternatives: When a potential attack is identified you need to validate and then remediate it. Don’t waste time shooting into the dark, so it’s important that you be able to see the impact of potential changes and workarounds to first figure out whether they would stop the attack, and then select the best option if you have several. Dynamic Security Assessment Process As usual we start our research by focusing on process rather than shiny widgets. The process is straightforward. Deployment: Your first step is to deploy assessment devices. You might refer to them as agents or sensors. But you will need a presence both inside and outside the network, to launch attacks and track results. Define Mission: After deployment you need to figure out what a typical attacker would want to access in your environment. This could be a formal threat modeling process, or you could start with asking the simple question, “What could be compromised that would cost the CEO/CFO/CIO/CISO his/her job?” Everything is important to the person responsible for it, but to find an adversary’s most likely target consider what would most drastically harm your business. Baseline/Triage: Next you need an initial sense of the vulnerability and exploitability of your environment, using a library of attacks to investigate its vulnerability. If you try, you can usually identify critical issues which immediately require all hands on deck. Once you get through the initial triage and remediation of potential attacks, you will have an initial activity baseline. Ongoing Assessment: Then you can start assessing your environment on an ongoing basis. An automated feed of new attack tactics and targets is useful for ensuring you look for the latest attacks seen in the wild. When an assessment engine finds something, administrators are alerted to successful attack paths and/or patterns for validation, and then criticality determination of a potential attack. This process needs to run continuously because things change in your environment from minute to minute. Fix: This step tends to be performed by Operations, and is somewhat opaque to the assessment process. But this is where critical issues are fixed and/or remediated. Verify Fixes: The final step is to validate that issues were actually fixed. The job is not complete until you verify that the fix is both operational and effective. Yes, that all looks a lot like every other security assessment methodology you have seen. What needs to happen hasn’t really changed – you still need to figure out exposure, understand criticality, fix, and then make sure the fixes worked. What has changed is the technology used for assessment. This is where the industry has made significant strides to improve both accuracy and usefulness. Assessment Engine The centerpiece of DSA is what we call an assessment engine. It’s how you understand what is possible in an environment, to define the universe of possible attacks, and then figure out which would be most damaging. This effectively reduces the detection window, because without it you don’t know if an attack has been used on you; it also helps you prioritize remediation efforts, by focusing on what would work against your defenses. You feed your assessment engine the topology of your network, because attackers need to first gain a foothold in your network, and then move laterally to achieve their mission. Once your engine has a map of your network, existing security controls are factored in so the engine can determine which devices are vulnerable to which attacks. For instance you’ll want to define access control points (firewalls) and threat detection (intrusion prevention) points in the network, and what kinds of controls run on which endpoints. Attacks almost always involve both networks and endpoints, so your assessment engine must be able to simulate both. Then the assessment engine can start figuring out what can be attacked and how. The best practices of attackers are distilled into algorithms to simulate how an attack could hit across multiple networks and devices. To illuminate the concept a bit, consider the attack lifecycle/kill chain. The engine simulates reconnaissance from both inside and outside your network to determine what is visible and where to move next in search of its target. It is important to establish presence, and to gather data from both inside and outside your network, because attackers will be working to do the same. Sometimes they get lucky and are invited in by unsuspecting employees, but other times they look for weaknesses in perimeter defenses and applications. Everything is fair game and thus should be subject to DSA. Then the simulation should deliver the attack to see what would compromise that device. With an idea of which controls are active on the device, you can determine which attacks might work. Using data from reconnaissance, an attack path from entry point to target can be generated. These paths represent lateral movement within the environment, and the magic

In the process of wrapping up the year I realize the last Incite I wrote was in August. Damn. That’s a long respite. It’s in my todo list every Tuesday. And evidently I have dutifully rescheduled it for about 3 months now. I am one to analyze (and probably overanalyze) everything, so I need to figure out why I have resisted writing the Incite. I guess it makes sense to go back to 2007, when I started writing the Incite. My motivation was to build my first independent research business (Security Incite), and back then a newsletter was the way to do it. I was pretty diligent about writing almost every day – providing inflammatory commentary on security news, poking the bear whenever I could, and making a name for myself. I think that was modestly successful, and it really reflected who I was back then. Angry, blunt, cynical, and edgy. So the Incite persona fit and I communicated that through my blog, speaking gigs, and strategy work for years. During that initial period I also started adding some personal stories and funny anecdotes to lighten it up a bit. Mostly because I was getting bored – it’s not like security news is the most exciting thing to work on every day. But the feedback on my personal stories was great, so I kept doing it. So basically the Incite turned into my playground, where I could share pretty much anything going on with me. And I did. The good, bad, and ugliness of life. As I went through a period of turbulence and personal evolution (midlife transformation), I used the Incite as my journal. Only I know a lot of the underlying machinations that drove many of those posts, but the Incite allowed me to document my journey. For me. I got through the proverbial tunnel back in July of 2015. Obviously I’m still learning and growing (mostly by screwing things up), but I didn’t feel compelled to continue documenting my journey. I did learn a lot through the process, so I wanted to share my experiences and associated philosophies, since that was how I coped with my personal turmoil. I also hoped that my writing would help other folks in similar situations. But I don’t seem to have a lot of ground left to cover, and since I’ve moved forward in my personal life, I don’t want to keep digging into the past. Where does that leave me now? The reality is that the Incite persona no longer fits. I’ve been alluding to that for a while, and on reflection, it’s left me a little untethered and resistant to writing. My resistance comes from having to maintain a persona I no longer want. Grumpy Mike is an act. And I no longer want to play that role. When people you just meet tell you, “you’re not so mean,” it’s time to rehabilitate your image. But the Incite perpetuates that perception. When looking at a situation without an easy answer, my teacher Casey always counseled me to flip the perspective. Look at it from a different viewpoint and see if a solution appears. Since I seem to be triggered by the word ‘Incite’, let’s dig into that. It’s clear the idea of encouraging “violent or unlawful behavior” is the problem. But if I look at the synonyms, I see words that do reflect what I’m trying to do. Encourage, stimulate, excite, awaken, inspire, and trigger. I always wrote the Incite for me, but based on many many discussions and notes of support I’ve received, it has done many of these things for readers. And that makes me happy. Everything changes. I’m living, breathing proof of that. And it’s time to move forward. So I’m going to retire the Incite newsletter. That writing is an important release for me and I still like to share anecdotes, so I’ll continue doing that in some way, shape, or form. And I’m going to get better about doing 3-5 quick security news analyses each week as well, since we are kind of a security research firm. But it won’t stop there. I will be launching some new services early next year to develop the next generation of security leaders, so I’ll be integrating weekly video interviews and other personal development content into the mix as well. I know 2016 was hard for many people. From my perspective there were certainly surprises. Overall it was a good year for me and my family. I have a lot to celebrate and be thankful for. So I’ll spend my holiday season catching up on projects that dragged out (meaning I’ll be active on the blog) and pinching myself, just to make sure this is all real. –Mike Share:

Big 9. Lucky 9. Or maybe not so lucky 9, because by the time you reach our annual respite from the wackiness of the RSA Conference, you may not be feeling very lucky. But if you flip your perspective, you’ll be in the home stretch, with only one more day of the conference before you can get the hell out of SF. We are happy to announce this year’s RSA Conference Disaster Recovery Breakfast. It’s hard to believe this is our ninth annual event. Everything seems to be in a state of flux and disruption. It’s a bit unsettling. But we’re happy to help you anchor at least for a few hours to grab some grub, drinks, and bacon. We remain grateful that so many of our friends, clients, and colleagues enjoy a couple hours away from the monstrosity that is now the RSAC. By Thursday we’re all disasters, so it’s very nice to have a place to kick back, have some conversations at a normal decibel level, and grab a nice breakfast. Or don’t talk to anyone at all and embrace your introvert – we get that too. With the continued support of Kulesa Faul, CHEN PR, and LaunchTech, you’ll have a great opportunity to say hello and thank them for helping support your habits. We are also very happy to welcome the CyberEdge Group as a partner. They are old friends, and we are ecstatic to have them participate. As always the breakfast will be Thursday morning (February 16) from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We will have food, beverages, and assorted non-prescription recovery items to ease your day. Yes, the bar will be open – Mike gets the DTs if he doesn’t have his rise and shine Guinness. Please remember what the DR Breakfast is all about. No marketing, no spin, no t-shirts, and no flashing sunglasses – it’s just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. We are confident you will enjoy the DRB as much as we do. See you there. To help us estimate numbers, please RSVP to rsvp (at) securosis (dot) com. Share:

Big 9. Lucky 9. Or maybe not so lucky 9, because by the time you reach our annual respite from the wackiness of the RSA Conference, you may not be feeling very lucky. But if you flip your perspective, you’ll be in the home stretch, with only one more day of the conference before you can get the hell out of SF. We are happy to announce this year’s RSA Conference Disaster Recovery Breakfast. It’s hard to believe this is our ninth annual event. Everything seems to be in a state of flux and disruption. It’s a bit unsettling. But we’re happy to help you anchor at least for a few hours to grab some grub, drinks, and bacon. We remain grateful that so many of our friends, clients, and colleagues enjoy a couple hours away from the monstrosity that is now the RSAC. By Thursday we’re all disasters, so it’s very nice to have a place to kick back, have some conversations at a normal decibel level, and grab a nice breakfast. Or don’t talk to anyone at all and embrace your introvert – we get that too. With the continued support of Kulesa Faul, CHEN PR, and LaunchTech, you’ll have a great opportunity to say hello and thank them for helping support your habits. We are also very happy to welcome the CyberEdge Group as a partner. They are old friends, and we are ecstatic to have them participate. As always the breakfast will be Thursday morning (February 16) from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We will have food, beverages, and assorted non-prescription recovery items to ease your day. Yes, the bar will be open – Mike gets the DTs if he doesn’t have his rise and shine Guinness. Please remember what the DR Breakfast is all about. No marketing, no spin, no t-shirts, and no flashing sunglasses – it’s just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. We are confident you will enjoy the DRB as much as we do. See you there. To help us estimate numbers, please RSVP to rsvp (at) securosis (dot) com.   Share:

I realized I promised to start writing more again to finish off the year and then promptly disappeared for over a week. Not to worry, it was for a good cause, since I spent all of last week at Amazon’s re:Invent conference. And, umm, might have been distracted this week by the release of the Rogue One expansion pack for Star Wars Battlefront. But enough about me… Here are my initial thoughts about re:Invent and Amazon’s direction. It may seem like I am biased towards Amazon Web Services, for two reasons. First, they still have a market lead in terms of both adoption and available services. That isn’t to say other providers aren’t competitive, especially in particular areas, but Amazon has maintained a strong lead across the board. This is especially true of security features and critical security capabilities. Second, most of my client work is still on AWS, so I need to pay more attention to it – selection bias. Although Azure and Google are slowly creeping in. With that out of the way, here’s my analysis of the event’s announcements: The biggest security news wasn’t security products. With security we tend to get a bit myopic, and focus on security products and features, but the real impact on our practices nearly always comes from broader changes to IT adoption patterns and technologies. Last week Amazon laid out the future of computing and there is plenty of evidence that Microsoft and Google are well along the same path, if not ahead: The future is serverless: When you use a cloud load balancer, you don’t run an instance or a virtual machine – you just request a load balancer. Sure, somewhere it’s running on hardware and an operating system, but all that is hidden from you, and the cloud provider takes responsibility for managing nearly all the security. That’s great for things like load balancers, message queues, and even the occasional database, but what about your custom code? That’s where AWS Lambda comes, in and Amazon has tripled down. Lambda lets you load code into the cloud, which AWS runs on demand (in a Linux container). You just write your code and don’t worry about the rest. AWS announced enhancements to Lambda, but the big product piece is Step Functions that allow you to tie together application components with a state machine (I’m simplifying). The net result? More, bigger, serverless applications, and a gap which kept Lambda out of complex projects has been closed. Security take? Serverless blows apart nearly all our existing security models. I’m not kidding – it’s insanely disruptive. This post is already going to be too long, so I’ll start a series on this soon. The future is serverless AI: Amazon released a quad of artificial intelligence tools. Image recognition, conversational interfaces (like Alexa, Google Now, and Siri), text to speech, and accessible machine learning (a set of features that doesn’t require you to program machine learning from scratch). Go read the descriptions and watch the demos – these are really interesting and powerful capabilities. Security take? Prepare for more data to flow into the cloud… and stay there. You simply can’t compete with these capabilities on-premise. On the upside, we can also harness these to improve security analysis and operations. The future is distributed and ever-present: Those Lambda functions? Amazon announced they are now accessible on edge routers (sorry Akamai), in big-storage Snowball appliances (a smart NAS you can drop anywhere that will process locally and communicate with the cloud, or you just ship it all to Amazon for data storage), and in IoT devices on the friggin’ silicon. All feeding back into the cloud. Amazon is extending its processing engine to basically everywhere (IoT FTW). Security take? This is enterprise-targeted IoT, combined with distributed mesh computing. Hang on to your hats. Security is still core to AWS, but their focus is on reducing friction. None of what I described above can work without a bombproof security baseline. This was the first re:Invent I’ve been to where there were no security announcements in the Day 1 keynote. They announced DDoS on Day 2 and a bunch of enhancements during the State of Security track lead-off presentation. It seemed almost understated until you went to the various sessions and saw the bigger picture. When AWS builds security products like KMS or Inspector it’s mostly to reduce the friction of security and compliance when customers want to move to AWS. They step in when they see existing products failing or slowing down AWS adoption, for core features they need themselves, and when they think an improvement will bring more clients. Don’t assume a low level of announcements means a low level of commitment or capabilities – it’s just that security is becoming more of the fabric. For example Lambda gives you basically a super-hardened server to run arbitrary code – that’s much more important than… Multiple account management. Finally. It’s easy for me to recommend using 2-5 accounts per project, but managing accounts at enterprise scale on AWS is a major pain in the ass. Organizations is the first step into enabling master and sub accounts. It’s in preview, and although I applied I’m not in yet so I don’t have a lot of details. But this helps resolve the single biggest pain point for most of my cloud-native customers. Anti-DDoS. Finally. You can’t use BGP based anti-DDoS with AWS which has limited everyone to cloud-based web services. I’m a huge fan, but they don’t work well with all AWS services – especially when you use the CDN. Now everyone gets basic anti-DDoS for free and advanced anti-DDoS (humans watching and troubleshooting) is pretty darn cost effective. Sorry Akamai (and Cloudflare and Incapsula). Actually, Amazon’s WAF capabilities are still limited enough that DDoS + cloud WAF vendors should be okay… for a while. Systems Manager adds automated image creation, patch, and configuration management. EC2 Systems Manager is a collection of tools to knock down those problems. But