Research

The explosive growth of containers is not surprising – technologies such as Docker address several problems facing developers when they deploy applications. Developers need simple packaging, rapid deployment, reduced environmental dependancies, support for micro-services, and horizontal scalability – all of which containers provide, making them very compelling. Yet this generic model of packaged services, where the environment is designed to treat each container as a “unit of service” sharply reduces transparency and auditability (by design) and gives security pros nightmares. We run more code and run it faster, begging the question, “How can you introduce security without losing the benefits of containers?” IT and Security teams lack visibility into containers, and have trouble validating them – both before placing them into production, and once they are running in production. Their peers on the development team are often disinterested in security, and cannot be bothered with providing reports and metrics. This is essentially the same problem we have for application security in general: the people responsible for the code are not incentivized to make security their problem, and the people who want to know what’s going on lack visibility. In this research we will delve into container technology, its unique value proposition, and how it fits into the application development and management processes. We will offer advice on how to build security into the container build process, how to validate and manage container inventories, and how to protect the container run-time environment. We will discuss applicability, both for pre-deployment testing and run-time security. Our hypothesis is that containers are scaring the hell out of security pros because of their lack of transparency. The burden of securing containers falls across development, operations, and security teams; but not of these audiences are sure how to tackle the problem. This research is intended to aid security practitioners and IT operations teams in selecting tools and approaches for container security. We are not diving into how to secure apps in containers here – instead we are limiting ouselves to build, container management, deployment, and runtime security for the container environment. We will focus on Docker security as the dominant container model today, but will comment on other options as appropriate – particularly Google and Amazon services. We will not go into detail on the Docker platform’s native security offerings, but will mention them as part of an overall strategy. Our working title is “Assembling a Container Security Program”, but that is open for review. Our outline for this series is: Threats and Concerns: We will outline why container security is difficult, with a dive into the concerns of malicious containers, trust between containers and the runtime environment, container mismanagement, and hacking the build environment. We will discuss the areas of responsibility for Security, Development, and Operations. Securing the Build: This post will cover the security of the build environment, where code is assembled and containers are constructed. We will consider vetting the contents of the container, as well as how to validate supporting code libraries. We will also discuss credential management for build servers to help protect against container tampering, code insertion and misuse through assessment tools, build tool configuration, and identity management. We will offer suggestions for Continuous Integration and DevOps environments. Validating the Container: Here we will discuss methods of container management and selection, as well as ways to ensure selection of the correct containers for placement into the environment. We will discuss approaches for container validation and management, as well as good practices for response when vulnerabilities are found. Protect the Runtime Environment: This post will cover protecting the runtime environment from malicious containers. We will discuss the basics of host OS security and container engine security. This topic could encompass an entire research paper itself, so we will only explore the basics, with pointers to container engine and OS platform security controls. And we will discuss use of identity management in cloud environments to restrict container permissions at runtime. Monitoring and Auditing: Here we will discuss the need to verify that containers are behaving as intended; we will break out use of logging, real-time monitoring, and activity auditing for container environments. We will also discuss verification of code behavior – through both sandboxing and API monitoring. Containers are not really new, but container security is still immature. So we are in full research mode with this project, and as always we use an open research model. The community helps make these research papers better – by both questioning our findings and sharing your experiences. We want to hear your questions, concerns, and experiences. Please reach out to us via email or leave comments. Our next post will address concerns we hear from security and IT folks. Share:

Every enterprise uses cloud computing services to some degree – tools such as Gmail, Twitter, and Dropbox are ubiquitous; as are business applications like Salesforce, ServiceNow, and Quickbooks. Cost savings, operational stability, and reduced management effort are all proven advantages. But when we consider moving back-office infrastructure – systems at the heart of business – there is significant angst and uncertainty among IT and security professionals. For big and complex applications like SAP, they wonder if cloud services are a viable option. The problem is that security is not optional, but actually critical. For folks operating in a traditional on-premise environment, it is often unclear how to adapt the security model to an unfamiliar environment where they only have partial control. We have been receiving an increasing number of questions on SAP cloud security, so today we are kicking off a new research effort to address major questions on SAP cloud deployment. We will examine how cloud services are different and how to adapt to produce secure deployments. Out main focus areas will be the division of responsibility between you and your cloud vendor, which tools and approaches are viable, changes to the operational model, and advice for putting together a cloud security program for SAP. Cloud computing infrastructure faces many of the same challenges as traditional on-premise IT. We are past legitimately worrying that the cloud is “less secure”. Properly implemented, cloud services are as secure – in many cases more secure – than on-premise applications. But “proper implementation” is tricky – if you simply “lift and shift” your old model into the cloud, we know from experience that it will be less secure and cost more to operate. To realize the advantages of the cloud you need to leverage its new features and capabilities – which demands a degree of re-engineering for architecture, security program, and process. SAP cloud security is tricky. The main issue is that there is no single model for what an “SAP Cloud” looks like. From many, it’s Hana Enterprise Cloud (HEC), a private cloud within the existing on-premise domain. Customers who don’t modify or extend SAP’s products can leverage SAP’s Software as a Service (SaaS) offering. But a growing number of firms we speak with are moving to SAP’s Hana Cloud Platform (HCP), a Platform as a Service (PaaS) bundle of the core SAP Hana application with data management features. Alternatively, various other cloud services can be bundled or linked to build a cloud plastform for SAP – often including mobile client access ‘enablement’ services and supplementary data management (think big data analytics and data mining). But we find customers do not limit themselves only to SAP software – they blend SAP cloud services with other major IaaS providers, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure to create ‘best-of-breed’ solutions. In response, SAP has published widely on its vision for cloud computing architectures, so we won’t cover that in detail here, but they promote hybrid deployments centered around Hana Cloud Platform (HCP) in conjunction with on-premise and/or public IaaS clouds. There is a lot to be said for the flexibility of this model – it enables customers to deploy applications into the cloud environments they are comfortable with, or to choose one optimal for their applications. But this flexibility comes at the price of added complexity, making it more difficult to craft a cohesive security model. So we will focus on the use of the HCP service, discussing security issues around hybrid architectures as appropriate. We will cover the following areas: Division of Responsibility: This post will discuss the division of responsibility between the cloud provider and you, the tenant. We will talk about where the boundary lands in different cloud service models (specifically SaaS, PaaS, and IaaS). We will discuss new obligations (particularly the cloud provider’s responsibilities), the need to investigate which security tools and information they provide, and where you need to fill in the gaps. Patching, configuration, breach analysis, the ability to assess installations, availability of event data, and many other considerations come into play. We will discuss the importance of contracts and service definitions, as well as what to look for when addressing compliance concerns. We will briefly address issues of jurisdiction and data privacy when considering where to deploy SAP servers and failover systems. Cloud Architectures and Security Models: SAP’s cloud service offers many feature which are similar to their on-premise offerings. But cloud deployments disrupt traditional security controls, and reliance on old-school network scanning and monitoring no longer works in multi-tenant environments on virtual networks. So this post will discuss how to evolve your approach for security, particularly in application architecture and the security selection process. We will cover the major areas you need to address when mapping your security controls to cloud-enabled security technologies. We will explore some issues with current preventive security controls, cluster configuration, and logging. Application Security: Cloud deployments free us of many burdens of patching, server maintenance, and physical network segregation. But we are still responsible for many application-layer security controls – including SAP applications, your application code, and supporting databases. And many cloud vendor services impact application configuration. This post will discuss preventive security controls in areas such as configuration, assessment, and identity management; as well as how to approach patch management. We will also discuss real-time security in monitoring, data security, logging, and analytics. And we will discuss security controls missing from SAP cloud services. Security Operations in Cloud Environments: The cloud fundamentally changes IT operations, for the better. Traditional concepts of how to provide reliability and security are turned on their ear in cloud environments. Most IT and security personnel don’t fully grasp the challenges – or opportunities. This post will present the advantages of ephemeral servers, automation, virtual networks, API enablement, and fine-grained authorization. We will discuss automation and orchestration of security tasks through APIs and scripts, how to make patching less painful, and how to deploy security as part of your application

As we return to our Endpoint Advanced Protection series, let’s dig into the lifecycle alluded to at the end of our introduction. We laid out a fairly straightforward set of activities required to protect endpoint devices. But we all know straightforward doesn’t mean easy. At some point you need to decide where endpoint protection starts and ends. Additionally, figuring out how it will integrate with the other defenses in your environment is critical because today’s attacks require more than just a single control – you need an integrated system to protect devices. The other caveat before we jump into the lifecycle is that we are actually trying to address the security problem here, not merely compliance. We aim to actually protect devices from advanced attacks. Yes, that is a very aggressive objective, some say crazy, given how fast our adversaries learn. But we wouldn’t be able to sleep at night if we merely accepted mediocrity the of our defenses, and we figure you are similar… so let’s aspire to this lofty goal. Gaining Visibility: You cannot protect what you don’t know about – that hasn’t changed, and isn’t about to. So the first step is to gain visibility into all devices that have access to sensitive data within your environment. It’s not enough to just find them – you also need to assess and understand the risk they pose. We will focus on traditional computing devices, but smartphones and tablets are increasingly used to access corporate networks. Reducing Attack Surface: Once you know what’s out there, you want to make it as difficult as possible for attackers to compromise it. That means practicing good hygiene on devices – making sure they are properly configured, patched, and monitored. We understand many organizations aren’t operationally excellent, but protection is much more effective after you get rid of the low-hanging fruit which making it easy for attackers. Preventing Threats: Next try to stop successful attacks. Unfortunately, despite continued investment and promises of better results, the results are still less than stellar. And with new attacks like ransomware making compromise even worse, the stakes are getting higher. Technology continues to advance, but we still don’t have a silver bullet that prevents every attack… and we never will. It is now a question of reducing attack surface as much as practical. If you can stop the simple attacks, you can focus on advanced ones. Detecting Malicious Activity: You cannot prevent every attack, so you need a way to detect attacks after they penetrate your defenses. There are a number of detection options. Most of them are based on watching for patterns that indicate a compromised device, but there are many other indicators which can provide clues to a device being attacked. The key is to shorten the time between when a device is compromised and when you realize it. Investigating and Responding to Attacks: Once you determine a device has been compromised, you need to verify the successful attack, determine your exposure, and take action to contain the damage as quickly as possible. This typically involves a triage effort, quarantining the device, and then moving to a formal investigation – including a structured process for gathering forensic data, establishing an attack timeline to help determine the attack’s root cause, an initial determination of potential data loss, and a search to determine how widely the attack spread within your environment. Remediation: Once the attack has been investigated, you can put a plan in place to recover. This might involve cleaning the machine, or re-imaging it and starting over again. This step can leverage ongoing hygiene tools such as patch and configuration management, because there is no point reinventing the wheel; tools to accomplish the necessary activities are already in use for day-to-day operations. Gaining Visibility You need to know what you have, how vulnerable it is, and how exposed it is. With this information you can prioritize your exposure and design a set of security controls to protect your assets. Start by understanding what in your environment would interest an adversary. There is something of interest at every organization. It could be as simple as compromising devices to launch attacks on other sites, or as focused as gaining access to your environment to steal your crown jewels. When trying to understand what an advanced attacker is likely to come looking for, there is a fairly short list of asset types – including intellectual property, protected customer data, and business operational data (proposals, logistics, etc.) Once you understand your potential targets, you can begin to profile adversaries likely to be interested in them. The universe of likely attacker types hasn’t changed much over the past few years. You face attacks from a number of groups across the continuum of sophistication. Starting with unsophisticated attackers (which can include a 400 pound hacker in a basement, who might also be a 10-year-old boy), organized crime, competitors, and/or state-sponsored adversaries. Understanding likely attackers provides insight into probable tactics, so you can design and implement security controls to address those risks. But before you can design a security control set, you need to understand where the devices are, as well as their vulnerabilities. Discovery This process finds the devices accessing critical data and makes sure everything is accounted for. This simple step helps to avoid “oh crap” moments – it’s no fun when you stumble over a bunch of unknown devices with no idea what they are, what they have access to, or whether they are cesspools of malware. A number of discovery techniques are available, including actively scanning your entire address space for devices and profiling what you find. This works well and is traditionally the main method of initial discovery. You can supplement with passive discovery, which monitors network traffic to identify new devices from network communications. Depending on the sophistication of the passive analysis, devices can be profiled and vulnerabilities can be identified, but the primary goal of passive monitoring is to discover unmanaged devices faster. Passive discovery

It’s been a long time since I had an office job. I got fired from my last in November 2005. I had another job since then, but I commuted to Boston. So I was in the office maybe 2-3 days a week. But usually not. That means I rarely have a bad commute. I work from wherever I want, usually some coffee shop with headphones on, or in a quiet enough corner to take a call. I spend some time in the home office when I need to record a webcast or record a video with Rich and Adrian. So basically I forgot what it’s like to work in an office every day. To be clear, I don’t have an office job now. But I am helping out a friend and providing some marketing coaching and hands-on operational assistance in a turn-around situation. I show up 2 or 3 days a week for part of the day, and I now remember what it’s like to work in an office. Honestly, I have no idea how anyone gets things done in an office. I’m constantly being pulled into meetings, many of which don’t have to do with my role at the company. I shoot the breeze with my friends and talk football and family stuff. We do some work, which usually involves getting 8 people in a room to tackle some problem. It’s horribly inefficient, but seems to be the way things get done in corporate life. Why have 2 people work through an issue when you can have 6? Especially since the 4 not involved in the discussion are checking email (maybe) or Facebook (more likely). What’s the sense of actually making decisions when you have to then march them up the flagpole to make sure everyone agrees? And what if they don’t? Do Not Pass Go, Do Not Collect $200. Right, I’m not really cut out for an office job. I’m far more effective with a very targeted objective, with the right people to make decisions present and engaged. That’s why our strategy work is so gratifying for me. It’s not about sitting around in a meeting room, drawing nice diagrams on a whiteboard wall. It’s about digging into tough issues and pushing through to an answer. We’ve got a day. And we get things done in that day. As an aside, whiteboard walls are cool. It’s like an entire wall is a whiteboard. Kind of blew my mind. I stood on a chair and wrote maybe 12 inches from the ceiling. Just because I could, and then I erased it! It’s magic. The little things, folks. The little things. But I digress. As we continue to move forward with our cloud.securosis plans, I’m going to carve out some time to do coaching and continue doing strategy work. Then I can be onsite for a day, help define program objectives and short-term activities, and then get out before I get pulled into an infinite meeting loop. We follow up each week and assess progress, address new issues, and keep everything focused. And minimal meetings. It’s not that I don’t relish the opportunity to connect with folks on an ongoing basis. It’s fun to catch up with my friends. I also appreciate that someone else pays for my coffee and snacks especially since I drink a lot of coffee. But I’ve got a lot of stuff to do, and meetings in your office aren’t helping with that. –Mike Photo credit: “no meetings” from autovac Security is changing. So is Securosis. Check out Rich’s post on how we are evolving our business. We’ve published this year’s Securosis Guide to the RSA Conference. It’s our take on the key themes of this year’s conference (which is really a proxy for the industry), as well as deep dives on cloud security, threat protection, and data security. And there is a ton of meme goodness… Check out the blog post or download the guide directly (PDF). The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour. Your emails, alerts, and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our video podcast? Rich, Adrian, and Mike get into a Google Hangout and… hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. May 31 – Where to Start? May 2 – What the hell is a cloud anyway? Mar 16 – The Rugged vs. SecDevOps Smackdown Feb 17 – RSA Conference – The Good, Bad and Ugly Dec 8 – 2015 Wrap Up and 2016 Non-Predictions Nov 16 – The Blame Game Nov 3 – Get Your Marshmallows Oct 19 – re:Invent Yourself (or else) Aug 12 – Karma July 13 – Living with the OPM Hack May 26 – We Don’t Know Sh–. You Don’t Know Sh– May 4 – RSAC wrap-up. Same as it ever was. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Managed Security Monitoring Selecting a Service Provider Use Cases Evolving Encryption Key Management Best Practices Use Cases Part 2 Introduction Maximizing WAF Value [Management]/blog/maximizing-waf-value-managing-your-waf) Deployment Introduction Recently Published Papers Understanding and Selecting RASP Incident Response in the Cloud Age Building a Threat Intelligence Program Shining a Light on Shadow Devices Building Resilient Cloud Network Architectures Building a Vendor (IT) Risk Management Program SIEM Kung Fu Securing Hadoop Threat Detection Evolution Building Security into DevOps Pragmatic Security for Cloud and Hybrid Networks Applied Threat Intelligence Endpoint Defense: Essential Practices Best Practices for AWS Security The Future of Security Incite 4 U Deputize everyone for security: Our friend Adrian

I had a call today, that went pretty much like all my other calls. An organization wants to move to the cloud. Scratch that – they are moving, quickly. The team on the phone was working hard to figure out their architectures and security requirements. These weren’t ostriches sticking their heads in the sand, they were very cognizant of many of the changes cloud computing forces, and were working hard to enable their organization to move as quickly and safely as possible. They were not blockers. The company was big. I take a lot of these calls now. The problem was, as much as they’ve learned, as open minded as they were, the team was both getting horrible advice (mostly from their security vendors) and facing internal pressure taking them down the wrong path. This wasn’t a complete lift and shift, but it wasn’t really cloud-native, and it’s the sort of thing I now see frequently. The organization was setting up a few cloud environments at their provider, directly connecting everything to extend their network, and each one was at a different security level. Think Dev/Test/Prod, but using their own classification. The problem is, this really isn’t a best practice. You cannot segregate out privileged users well at the cloud management level. It adds a bunch of security weaknesses and has a very large blast radius if an attacker gets into anything. Even network security controls become quite complex. Especially since their existing vendors were promising they could just drop virtual appliances in and everything would work like just it does on-premise – no, it really doesn’t. This is before we even get into using PaaS, serverless architectures, application-specific requirements, tag and security group limitations, and so on. It doesn’t work. Not at scale. And by the time you notice, you are very deep inside a very expensive hole. I used to say the cloud doesn’t really change security. That the fundamentals are the same and only the implementation changes. Since about 2-3 years ago, that is no longer true. New capabilities started to upend existing approaches. Many security principles are the same, but all the implementation changes. Process and technology. It isn’t just security – all architectures and operations change. You need to take what you know about securing your existing infrastructure, and throw it away. You cannot draw useful parallels to existing constructs. You need to take the cloud on its own terms – actually, on your particular providers’ terms – and design around that. Get creative. Learn the new best practices and patterns. Your skills and knowledge are still incredibly important, but you need to apply them in new ways. If someone tells you to build out a big virtual network and plug it into your existing network, and just run stuff in there, run away. That’s one of the biggest signs they don’t know what the f— they are talking about, and it will cripple you. If someone tells you to take all your existing security stuff and just virtualize it, run faster. How the hell can you pull this off? Start small. Pick one project, set it up in its own isolated area, rework the architecture and security, and learn. I’m no better than any of you (well, maybe some of you – this is an election year), but I have had more time to adapt. It’s okay if you don’t believe me. But only because your pain doesn’t affect me. We all live in the gravity well of the cloud. It’s just that some of us crossed the event horizon a bit earlier, that’s all. Share:

We are pleased to announce the availability of our Understanding RASP (Runtime Application Self-Protection) research paper. We would like to heartily thank Immunio for licensing this content. Without this type of support we could not bring this level of research to you, both free of charge and without requiring registration. We think this research paper will help developers and security professionals who are tackling application security from within. Our initial motivation for this paper was questions we got from development teams during our Agile Development and DevOps research efforts. During each interview we received questions about how to embed security into the application and the development lifecycle. The people asking us wanted security, but they needed it to work within their development and QA frameworks. Tools that don’t offer RESTful APIs, or cannot deploy within the application stack, need not apply. During these discussions we were asked about RASP, which prompted us to dive in. As usual, during this research project we learned several new things. One surprise was how much RASP vendors have advanced the application security model. Initial discussions with vendors showed several used a plug-in for Tomcat or a similar web server, which allows developers to embed security as part of their application stack. Unfortunately that falls a bit short on protection. The state of the art in RASP is to take control of the runtime environment – perhaps using a full custom JVM, or the Java JVM’s instrumentation API – to enable granular and internal inspection of how applications work. This model can provide assessments of supporting code, monitoring of activity, and blocking of malicious events. As some of our blog commenters noted, the plug-in model offers a good view of the “front door”. But full access to the JVM’s internal workings additionally enables you to deploy very targeted protection policies where attacks are likely to occur, and to see attacks which are simply not visible at the network or gateway layer. This in turn caused us to re-evaluate how we describe RASP technology. We started this research in response to developers looking for something suitable for their automated build environments, so we spent quite a bit of time contrasting RASP with WAF because to spotlight the constraints WAF imposes on development processes. But for threat detection, these comparisons are less than helpful. Discussions of heuristics, black and white lists, and other detection approaches fail to capture some of RASP’s contextual advantages when running as part of an application. Compared to a sandbox or firewall, RASP’s position inside an application alleviates some of WAF’s threat detection constraints. In this research paper we removed those comparisons; we offer some contrasts with WAF, but do not constrain RASP’s value to WAF replacement. We believe this technological approach will yield better results and provide the hooks developers need to better control application security. You can download the research paper, or get a copy from our Research Library. Share:

Innovation comes and goes in security. Back in 2007 network security had been stagnant for more than a few years. It was the same old, same old. Firewall does this. IPS does that. Web proxy does a third thing. None of them did their jobs particularly well, struggling to keep up with attacks encapsulated in common protocols. Then the next generation firewall emerged, and it turned out that regardless of what it was called, it was more than a firewall. It was the evolution of the network security gateway. The same thing happened a few years ago in endpoint security. Organizations were paying boatloads of money to maintain their endpoint protection, because PCI-DSS required it. It certainly wasn’t because the software worked well. Inertia took root, and organizations continued to blindly renew their endpoint protection, mostly because they didn’t have any other options. But in technology inertia tends not to last more than a decade or so (yes, that’s sarcasm). When there are billions of [name your favorite currency] in play, entrepreneurs, investors, shysters, and lots of other folks flock to try getting some of the cash. So endpoint security is the new hotness. Not only because some folks think they can make a buck displacing old and ineffective endpoint protection. The fact is that adversaries continue to improve, both in the attacks they use and the way they monetize compromised devices. One example is ransomware, which some organizations discover several times each week. We know of some organizations which tune their SIEM to watch for file systems being encrypted. Adversaries continue to get better at obfuscating attacks and exfiltration tactics. As advanced malware detection technology matures, attackers have discovered many opportunities to evade detection. It’s still a cat and mouse game, even though both cats and mice are now much better at it. Finally, every organization is still dealing with employees, who are usually the path of least resistance. Regardless of how much you spend on security awareness training, knuckleheads with access to your sensitive data will continue to enjoy clicking pictures of cute kittens (and other stuff…). So what about prevention? That has been the holy grail for decades. To stop attacks before they compromise devices. It turns out prevention is hard, so the technologies don’t work very well. Or they work, but in limited use cases. The challenge of prevention is also compounded by the shysters I mentioned above, who claim nonsense like “products that stop all zero days” – of course with zero, or bogus, evidence. Obviously they have heard you never let truth get in the way of marketing. Yes, there has been incremental progress, and that’s good news. But it’s not enough. On the detection side, someone realized more data could help detect attacks. Both close to the point of compromise, and after the attack during forensic investigation. So endpoint forensics is a thing now. It even has its own category, ETDR (Endpoint Threat Detection and Response), as named by the analysts who label these technology categories. The key benefit is that as more organizations invest in incident response, they can make use of the granular telemetry offered by these solutions. But they don’t really provide visibility for everyone, because they require security skills which are not ubiquitous. For those who understand how malware really works, and can figure out how attacks manipulate kernels, these tools provide excellent visibility. Unfortunately these capabilities are useless to most organizations. But we have still been heartened to see a focus on more granular visibility, which provides skilled incident responders (who we call ‘forensicators’) a great deal more data to figure out what happened during attacks. Meanwhile operating system vendors continue to improve their base technologies to be more secure and resilient. Not only are offerings like Windows 10 and OS X 10.11 far more secure, top applications (primarily office automation and browsers) have been locked down and/or re-architected for stronger security. We also have seen add-on tools to further lock down operating systems, such as Microsoft’s EMET). State of the Union: Sadness We have seen plenty of innovation. But the more things change, the more they stay the same. It’s a different day, but security professionals will still be spending a portion of it cleaning up compromised endpoints. That hasn’t changed. At all. The security industry also faces the intractable security skills shortage. As mentioned above, granular endpoint telemetry doesn’t really help if you don’t have staff who understand what the data means, or how similar attacks can be prevented. And most organizations don’t have that skill set in-house. Finally, users are still users, so they continue to click on things. Basically until you take away the computers. It is really the best of times and the worst of times. But if you ask most security folks, they’ll tell you it’s the worst. Thinking Differently about Endpoint Protection But it’s not over. Remember that “Nothing is over until we say it is.” (hat tip to Animal House – though be aware there is strong language in that clip). If something is not working, you had better think differently, unless you want to be having the same discussions in 10 years. We need to isolate the fundamental reason it’s so hard to protect endpoints. Is it that our ideas of how are wrong? Or is the technology not good enough? Or have adversaries changed so dramatically that all the existing ways to do endpoint security (or security in general) need to be tossed out? Fortunately technology which can help has existed for a few years. It’s just that not enough organizations have embraced the new endpoint protection methods. And many of the same organizations continue to be operationally challenged in security, which doesn’t help – you’re pretty well stuck if you cannot keep devices patched, or take too long to figure out someone is running a remote access trojan on your endpoints (and networks). So in this Endpoint Advanced Protection series, we will revisit and update the work

It should surprise no one that Apple is writing their own playbook for bug bounties. Both bigger, with the largest potential payout I’m aware of, and smaller, focusing on a specific set of vulnerabilities with, for now, a limited number of researchers. Many, including myself, are definitely free to be surprised that Apple is launching a program at all. I never considered it a certainty, nor even necessarily something Apple had to do. Personally, I cannot help but mention that this news hits almost exactly 10 years after Securosis started… with my first posts on, you guessed it, a conflict between Apple and a security researcher. For those who haven’t seen the news, the nuts and bolts are straightforward. Apple is opening a bug bounty program to a couple dozen select researchers. Payouts go up to $200,000 for a secure boot hardware exploit, and down to $25,000 for a sandbox break. They cover a total of five issues, all on iOS or iCloud. The full list is below. Researchers have to provide a working proof of concept and coordinate disclosure with Apple. Unlike some members of our community, I don’t believe bug bounties always make sense for the company. Especially for ubiquitous, societal, and Internet-scale companies like Apple. First, they don’t really want to get into bidding wars with governments and well-funded criminal organizations, some willing to pay a million dollars for certain exploits (including some in this program). On the other side is the potential deluge of low-quality, poorly validated bugs that can suck up engineering and communications resources. That’s a problem more than one vendor mentions to me pretty regularly. Additionally negotiation can be difficult. For example, I know of situations where a researcher refused to disclose any details of the bug until they were paid (or guaranteed payment), without providing sufficient evidence to support their claims. Most researchers don’t behave like this, but it only takes a few to sour a response team on bounties. A bug bounty program, like any corporate program, should be about achieving specific objectives. In some situations finding as many bugs as possible makes sense, but not always, and not necessarily for a company like Apple. Apple’s program sets clear objectives. Find exploitable bugs in key areas. Because proving exploitability with a repeatable proof of concept is far more labor-intensive than merely finding a vulnerability, pay the researchers fair value for their work. In the process, learn how to tune a bug bounty program and derive maximum value from it. High-quality exploits discovered and engineered by researchers and developers who Apple believes have the skills and motivations to help advance product security. It’s the Apple way. Focus on quality, not quantity. Start carefully, on their own schedule, and iterate over time. If you know Apple, this is no different than how they release their products and services. This program will grow and evolve. The iPhone in your pocket today is very different from the original iPhone. More researchers, more exploit classes, and more products and services covered. My personal opinion is that this is a good start. Apple didn’t need a program, but can certainly benefit from one. This won’t motivate the masses or those with ulterior motives, but it will reward researchers interested in putting in the extremely difficult work to discover and work through engineering some of the really scary classes of exploitable vulnerabilities. Some notes: Sources at Apple mentioned that if someone outside the program discovers an exploit in one of these classes, they could then be added to the program. It isn’t completely closed. Apple won’t be publishing a list of the invited researchers, but they are free to say they are in the program. Apple may, at its discretion, match any awarded dollars the researcher donates to charity. That discretion is to avoid needing to match a donation to a controversial charity, or one against their corporate culture. macOS isn’t included yet. It makes sense to focus on the much more widely used iOS and iCloud, both of which are much harder to find exploitable bugs on, but I really hope Macs start catching up to iOS security. As much as Apple can manage without such tight control of hardware. I’m very happy iCloud is included. It is quickly becoming the lynchpin of Apple’s ecosystem. It makes me a bit sad all my cloud security skills are defensive, not offensive. I’m writing this in the session at Black Hat, which is full of more technical content, some of which I haven’t seen before. And here are the bug categories and payouts: Secure boot firmware components: up to $200,000. Extraction of confidential material protected by the Secure Enclave, up to $100,000. Execution of arbitrary code with kernel privileges: up to $50,000. Unauthorized access to iCloud account data on Apple servers: up to $50,000. Access from a sandboxed process to user data outside that sandbox: up to $25,000. I have learned a lot more about Apple over the decade since I started covering the company, and Apple itself has evolved far more than I ever expected. From a company that seemed fine just skating by on security, to one that now battles governments to protect customer privacy. It’s been a good ten years, and thanks for reading. Share:

Incident response is always tough today. But when you need to deal with faster networks, an increasingly mobile workforce, and that thing called cloud computing, IR gets even harder. Sure, there are new technologies like threat intelligence, better network and endpoint telemetry, and analytics to help you investigate faster. But don’t think you’ll be able to do the same thing tomorrow as you did yesterday. You will need to evolve your incident response process and technology to handle the cloud age, just like you have had to adapt many of your other security functions to this new reality. Our Incident Response in the Cloud Age paper digs into impacts of the cloud, faster and virtualized networks, and threat intelligence on your incident response process. Then we discuss how to streamline response in light of the lack of people to perform the heavy lifting of incident response. Finally we bring everything together with a scenario to illuminate the concepts. We would like to thank SS8 for licensing this paper. Our Totally Transparent Research method provides you with access to forward-looking research without paywalls. Check out our research library or download the paper directly (PDF). Share:

One of the hardest things for me to realize has been that I don’t control everything. I spent years railing against the machine, and getting upset when nothing changed. Active-minded people (as opposed to passive) believe they make their own opportunities and control their destiny, sometimes by force of will. Over the past few years, I needed a way to handle this reality and not make myself crazy. So I came up with 3 “A” words that make sense to me. The first ‘A’, Acceptance, is very difficult for me because it goes against most of what I believe. When you think about it, acceptance seems so defeatist. How can you push things forward and improve them if you accept the way they are now? I struggled with this for the first 5 years I practiced mindfulness. What I was missing was the second ‘A’, Attachment. Another very abstract concept. But acceptance of what you can’t control is really contingent on not getting attached to how it works out. I would get angry when things didn’t work out the way I thought they should have. As if I were the arbiter of everything right and proper. LOL. If you are OK with however things work out, then there is no need to rail against the machine. Ultimately I had to acknowledge that everyone has their own path, and although their path may not make sense to me on my outsider’s perch, it’s not my place to judge whether it’s the right path for that specific person. Just because it’s not what I’d do, doesn’t mean it’s the wrong choice for someone else. In order to evolve and grow, I had to acknowledge there are just some things that I can’t change. I can’t change how other people act. I can’t change the decisions they make. I can’t change their priorities. Anyone with kids has probably banged heads with them because the kids make wrong-headed decisions and constantly screw up such avoidable situations. If only they’d listen, right? RIGHT? Or is that only me? This impacts every relationship you have. Your spouse or significant other will do things you don’t agree with. At work you’ll need to deal with decisions that don’t make sense to you. But at the end of the day, you can stamp your feet all you want, and you’ll end up with sore feet, but that’s about it. Of course in my role as a parent, advisor, and friend, I can make suggestions. I can offer my perspectives and opinions about what I’d do. But that’s about it. They are going to do whatever they do. This is hardest when that other person’s path impacts your own. In all aspects of our lives (both personal and professional) other people’s decisions have a significant effect on you. Both positive and negative. But what made all this acceptance and non-attachment work for me was that I finally understood that I control what I do. I control how I handle a situation, and what actions I take as a result. This brings us to the 3rd ‘A’, Adapt. I maintain control over my own situation by adapting gracefully to the world around me. Sometimes adapting involves significant alterations of the path forward. Other times it’s just shaking your head and moving on. I did my best to do all of the above as I moved forward in my personal life. I do the same on a constant basis as we manage the transition of Securosis. My goal is to make decisions and act with kindness and grace in everything I do. When I fall short of that ideal, I have an opportunity to accept my own areas of improvement, let go, and not beat myself up (removing Attachment), and Adapt to make sure I have learned something and won’t repeat the same mistake again. We all have plenty of opportunity to practice the 3 As. Life is pretty complicated nowadays, with lots of things you cannot control. This makes many people very unhappy. But I subscribe to the Buddhist proverb, “Pain is inevitable. Suffering is optional.” Acceptance, removing attachment, and adapting accordingly help me handle these situations. Maybe they can help you as well. –Mike Photo credit: “AAA” from Dennis Dixson Security is changing. So is Securosis. Check out Rich’s post on how we are evolving our business. We’ve published this year’s Securosis Guide to the RSA Conference. It’s our take on the key themes of this year’s conference (which is really a proxy for the industry), as well as deep dives on cloud security, threat protection, and data security. And there is a ton of meme goodness… Check out the blog post or download the guide directly (PDF). The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour. Your emails, alerts, and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our video podcast? Rich, Adrian, and Mike get into a Google Hangout and… hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. May 31 – Where to Start? May 2 – What the hell is a cloud anyway? Mar 16 – The Rugged vs. SecDevOps Smackdown Feb 17 – RSA Conference – The Good, Bad and Ugly Dec 8 – 2015 Wrap Up and 2016 Non-Predictions Nov 16 – The Blame Game Nov 3 – Get Your Marshmallows Oct 19 – re:Invent Yourself (or else) Aug 12 – Karma July 13 – Living with the OPM Hack May 26 – We Don’t Know Sh–. You Don’t Know Sh– May 4 – RSAC wrap-up. Same as it ever was. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy