By Mike Rothman
As we continue our research into the practical uses of threat intelligence (TI), we have documented how TI should change existing security monitoring (SM) processes. In our Leveraging Threat Intelligence in Security Monitoring paper, we go into depth on how to update your security monitoring process to integrate malware analysis and threat intelligence. Updating our process maps demonstrates that we don’t consider TI a flash in the pan – it is a key aspect of detecting advanced adversaries as we move forward.
Here is our updated process map for TI+SM.:
As much as you probably dislike thinking about other organizations being compromised, this provides a learning opportunity. An excerpt from the paper explains in more detail:
There are many different types of threat intelligence feeds and many ways to apply the technology – both to increase the effectiveness of alerting and to implement preemptive workarounds based on likely attacks observed on other networks. That’s why we say threat intelligence enables you to benefit from the misfortune of others. By understanding attack patterns and other nuggets of information gleaned from attacks on other organizations, you can be better prepared when they come for you.
And they will be coming for you – let’s be clear about that. So check out the paper and figure out how your processes need to evolve, both to keep pace with your adversaries, and to take advantage of all the resources now available to keep your defenses current.
We would like to thank Norse Corporation for licensing this paper. Without support from our clients, you wouldn’t be able to use our research without paying for it.
You can check out the permanent landing page for the paper, or download it directly (PDF).
Posted at Sunday 9th March 2014 11:00 am
(0) Comments •
By Mike Rothman
Our last AESP post covered a number of approaches to preventing attacks on endpoints and servers. Of course prevention remains the shiny object most practitioners hope to achieve. If they can stop the attack before the device is compromised there need be no clean-up. We continue to remind everyone that hope is not a strategy, and counting on blocking every attack before it reaches your devices always ends badly.
As we detailed in the introduction, you need to plan for compromise because it will happen. Adversaries have gotten much better, attack surface has increased dramatically, and you aren’t going to prevent every attack. So pwnage will happen, and what you do next is critical, both to protecting the critical information in your environment and to your success as a security professional.
So let’s reiterate one of our core security philosophies: Once the device is compromised, you need to shorten the window between compromise and when you know the device has been owned. Simple to say but very hard to do. The way to get there is to change your focus from prevention to a more inclusive process, including detection and investigation…
Our introduction described detection:
You cannot prevent every attack, so you need a way to detect attacks after they get through your defenses. There are a number of different options for detection – most based on watching for patterns that indicate a compromised device. The key is to shorten the time between when the device is compromised and when you discover it has been compromised.
To be fair, there is a gray area between detection and prevention, at least from an endpoint and server standpoint. With the exception of application control, the prevention techniques described in the last post depend on actually detecting the bad activity first. If you are looking at controls using advanced heuristics, you detect the malicious behavior first – then you block it. In an isolation context you run executables in the walled garden, but you don’t really do anything until you detect bad activity – then you kill the virtual machine or process under attack.
But there is more to detection than just figuring out what to block. Detection in the broader sense needs to include finding attacks you missed during execution because:
- You didn’t know it was malware at the time, which happens frequently – especially given how quickly attackers innovate. Advanced attackers have stockpiles of unknown exploits (0-days) they use as needed. So your prevention technology could be working as designed, but still not recognize the attack. There is no shame in that.
- Alternatively, the prevention technology may have missed the attack. This is common as well because advanced adversaries specialize in evading known preventative controls.
So how can you detect after compromise? Monitor other data sources for indicators that a device has been compromised. This series is focused on protecting endpoints and servers, but looking at devices is insufficient. You also need to monitor the network for a full perspective on what’s really happening, using a couple techniques:
- Network-based malware detection: One of the most reliable ways to identify compromised devices is to watch for communications with known botnets. You can look for specific traffic patterns, or for communications to known botnet IP addresses. We covered these concepts in both the NBMD 2.0 and TI+SM series.
- Egress/Content Filtering: You can also look for content that should not be leaving the confines of your network. This may involve a broad DLP deployment – or possibly looking for sensitive content on your web filters, email security gateways, and next generation firewalls.
Keep in mind that every endpoint and server device has a network stack of some sort. Thus a subset of this monitoring can be performed within the device, by looking at traffic that enters and leaves the stack.
As mentioned above, threat intelligence (TI) is making detection much more effective, facilitated by information sharing between vendors and organizations. With TI you can become aware of new attacks, emerging botnets, websites serving malware, and a variety of other things you haven’t seen yet and therefore don’t know are bad. Basically you leverage TI to look for attacks even after they enter your network and possibly compromise your devices. We call this retrospective searching. This works by either a) using file trajectory – tracking all file activity on all devices, looking for malware files/droppers as they appear and move through your network; or b) looking for attack indicators on devices with detailed activity searching on endpoints – assuming you collect sufficient endpoint data.
Even though it may seem like it, you aren’t really getting ahead of the threat. Instead you are looking for likely attacks – the reuse of tactics and malware against different organizations gives you a good chance to see malware which has hit others before long.
Once you identify a suspicious device you need to verify whether the device is really compromised. This verification involves scrutinizing what the endpoint has done recently for indicators of compromise or other such activity that would confirm a successful attack. We’ll describe how to capture that information later in this post.
Once you validate the endpoint has been compromised, you go into incident response/containment mode. We described the investigation process in the introduction as:
Once you detect an attack you need to verify the compromise and understand what it actually did. This typically involves a formal investigation, including a structured process to gather forensic data from devices, triage to determine the root cause of the attack, and searching to determine how broadly the attack has spread within your environment.
As we described in React Faster and Better, there are a number of steps in a formal investigation. We won’t rehash them here, but to investigate a compromised endpoint and/or server you need to capture a bunch of forensic information from the device, including:
- Memory contents
- Process lists
- Disk images (to capture the state of the file system)
- Registry values
- Executables (to support malware analysis and reverse engineering)
- Network activity logs
As part of the investigation you also need to understand the attack timeline. This enables you to identify the first compromised device (Patient Zero), as well as all affected devices, so you can effectively contain the damage when you reach the remediation phase. This timeline shows you how the malware got into your network in the first place, and how it proliferated to infect other devices.
This highlights one of the biggest problems in handling modern malware – getting rid of it completely. Even if you wipe an infected device to bare metal and reimage, unless you successfully identifying all other infected devices in your environment, and clean them all successfully, the malware will cause additional trouble. So as part of investigations you need to isolate all devices affected by the attack and clean them once and for all.
You can’t just rely on behavioral indicators (the device behaving badly) to identify additional affected devices, because the malware may be lying dormant and awaiting instructions from the bot master. You need to analyze detailed telemetry from endpoints and servers to determine whether these indicators are present – which brings us to the proverbial glue that enables both detection and investigation of attacks on endpoints and servers.
Capture Two Birds (with One Agent)
As we explained in our 2014 Endpoint Security Buyer’s Guide, to really investigate a device, you need to capture what’s happening on the endpoints and servers at a very granular level. This includes file activity, registry changes, privilege escalation, executed programs, network activity, and a variety of other activities happening on endpoints. We call this function Device Activity Monitoring, and it is also called ETDR (Enterprise Threat Detection and Response).
The key functions in device activity monitoring start with data capture. To get the data needed for a comprehensive investigation you need to capture data continuously. Of course that might not be practical on all devices, in which case you will use a trigger to start full collection. For example if a user clicks a link in an email that takes the browser to a suspicious site, you would start pulling detailed data from the endpoint, because a compromise is likely imminent.
Another capture decision is where to store the data. There is a battle brewing between products that capture this device telemetry data and store it on customer premises, and those which store data in the cloud. There are pros and cons to both approaches. On one side you will hear a lot about the security implications of moving such sensitive data to the cloud – and those are legitimate concerns. On the other hand, the need for large-scale analysis of aggregated and anonymized data, to identify emerging patterns across organizations, favors a cloud-based model. Mr. Market will determine the right approach soon enough, but where to store your telemetry data is definitely a deployment decision you need to make when selecting an approach.
Next, the activity monitoring technology should have adequate hooks for threat intelligence (TI) integration. The vendor’s research team can and should populate agents with emerging attack indicators, IP and file reputation, etc., to provide a basis for detecting advanced attacks. But one research feed is not enough so you will want a product flexible enough to ingest other feeds – likely through industry standard TI formats such as STIX, TAXII, OpenIOC, OTX, et al.
Finally, endpoints and servers generate a huge amount of data, so it’s also necessary for the product to perform big data style analysis on the telemetry dataset, to identify patterns and develop relationships between data sources. Having the data is the first step. Supplementing it with external information to help prioritize focus areas is second. Being able to analyze the data to provide useful information to security practitioners and incident responders is the third leg of the device activity monitoring triangle.
If you missed on prevention, you need to detect bad behavior by infected endpoints and servers, and then verify and investigate the attack. But that doesn’t entirely solve the problem – you still have active malware on the devices. Now it’s time to remediate.
Remediation tends to fall within the purview of Operations, but security teams can get a quick win by providing very detailed data and recommendations for remediation to Ops, to help focus their efforts and aid them in fully cleaning up the attack. We will discuss that Quick Win as we wrap up this series, in our next and final post.
Posted at Friday 7th March 2014 2:00 pm
(1) Comments •
By Adrian Lane
I don’t code much. In fact over the last 10 years or so I have been actively discouraged from coding, with at least one employer threatening to fire me if I was discovered. I have helped firms architect new products, I have done code reviews, I have done some threat modeling, and even a few small Java utilities to weave together a couple other apps. But there has been very, very little development in the last decade. Now I have a small project I want to do so I jumped in with both feet, and it feels like I was dumped into the deep end of the pool. I forgot how much bigger a problem space application development is, compared to simple coding.
In the last couple of days I have learned the basics of Ruby,
Node.js, Chef, and even Cucumber. I have figured out how to bounce between environments with RVM. I brushed up on some Python and Java. And honestly, it’s not very difficult. Learning languages and tools are trivial matters. A few hours with a good book or web site, some dev tools, and you’re running. But when you are going to create something more than a utility, everything changes. The real difficulty is all the different layers of questions about the big picture: architecture, deployment, UI, and development methodologies. How do you want to orchestrate activities and functions? How do you want to architect the system? How do you allow for customization? Do I want to do a quick prototype with the intention of rewriting once I have the basic proof of concept, or do I want to stub out the system and then use a test-driven approach? State management? Security? Portability? The list goes on.
I had forgotten a lot of these tasks, and those brain cells have not been exercised in a long time. I forgot how much prep work you need to do before you write a line of code. I forgot how easy it is to get sucked into the programming vortex, and totally lose track of time. I forgot the stacks of coffee-stained notes and hundreds of browser tabs with all the references I am reviewing. I forgot the need to keep libraries of error handling, input validation, and various other methods so I don’t need to recode them over and over. I forgot how much I eat when developing – when my brain is working at capacity I consume twice as much food. And twice as much caffeine. I forgot the awkwardness of an “Aha!” moment when you figure out how to do something, a millisecond before your wife realizes you haven’t heard a word she said for the last ten minutes. It’s all that. And it’s good.
On to the Summary:
Webcasts, Podcasts, Outside Writing, and Conferences
Favorite Securosis Posts
Other Securosis Posts
Favorite Outside Posts
Research Reports and Presentations
Top News and Posts
Blog Comment of the Week
This week’s best comment goes to Marco Tietz, in response to Research Revisited: FireStarter: Agile Development and Security, and you’ll have to watch the video to get it.
@Adrian: good video on Agile vs Security. But why did you have the Flying Spaghetti Monster in there and didn’t even give it credit! :) rAmen
Posted at Thursday 6th March 2014 11:40 pm
(0) Comments •
By Mike Rothman
After I got off the plane Friday night, picked my bag up off the carousel, took the train up to the northern Atlanta suburbs, got picked up by the Boss, said hello to the kids, and then finally took a breath – my first thought was that RSA isn’t real. But it is quite real, just not sustainable. That makes reentry into my day to day existence a challenge for a few days.
It’s not that I was upset to be home. It’s not that I didn’t want to see my family and learn about what they have been up to. My 5 minute calls two or three times a day, while running between meetings, didn’t give me much information. So I wanted to hear all about things. But first I needed some quiet. I needed to decompress – if I rose to the surface too quickly I would have gotten the bends.
For me the RSA Conference is a nonstop whirlwind of activity. From breakfast to the wee hours closing down the bar at the W or the Thirsty Bear, I am going at all times. I’m socializing. I’m doing business. I’m connecting with old friends and making new ones. What I’m not doing is thinking. Or recharging. Or anything besides looking at my calendar to figure out the next place I need to be. For an introvert, it’s hard. The RSA Conference is not the place to be introverted – not if you work for yourself and need to keep it that way.
I mean where else is it normal that dinner is a protein bar and shot of 5-hour energy, topped off with countless pints of Guinness? Last week that was not the exception, it was the norm. I was thankful we were able to afford a much better spread at the Security Blogger’s Meetup (due to the generosity of our sponsors), so I had a decent meal at least one night.
As I mentioned last week, I am not about to complain about the craziness, and I’m thankful the Boss understands my need to wind down on reentry. I make it a point to not travel the week after RSA, both to recharge, get my quiet time, and reconnect with the family.
The conference was great. Security is booming and I am not about to take that for granted. There are many new companies, a ton of investment coming into the sector, really cool innovative stuff hitting the market, and a general awareness that the status quo is no good. Folks are confused and that’s good for our business. The leading edge of practitioners are rethinking security and have been very receptive to research we have been doing to flesh out what that means in a clear, pragmatic fashion.
This is a great time to be in security. I don’t know how long it will last, but the macro trends seem to be moving in our direction. So I’ll file another RSA Conference into the memory banks and be grateful for the close friends I got to see, the fantastic clients who want to keep working with us, and the new companies I look forward to working with over the next year (even if you don’t know you’ll be working with us yet).
Even better, next year’s RSA Conference has been moved back to April 2015. So that gives me another two months for my liver to recover and my brain cells to regenerate.
PS: This year we once again owe huge thanks to MSLGROUP and Kulesa Faul, who made our annual Disaster Recovery Breakfast possible. We had over 300 people there and it was really great. Until we got the bill, that is…
Photo credit: “Reentry” originally uploaded by Evan Leeson
Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and, well, hang out. We talk a bit about security as well. We try to keep these less than 15 minutes, and usually fail.
2014 RSA Conference Guide
In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat.
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, where you can get all our content in its unabridged glory. And you can get all our research papers too.
Leveraging Threat Intelligence In Security Monitoring
Advanced Endpoint and Server Protection
Newly Published Papers
Incite 4 U
TI is whatever you want it to mean: Interesting experiment from FireEye/Mandiant’s David Bianco, who went around the RSA show floor and asked vendors what threat intelligence (TI) meant to vendors who used the term prominently in their booths. Most folks just use the buzzword, and mean some of the less sophisticated data sources. I definitely understand David’s perspective, but he is applying the wrong filter. It’s like of like having a Ph.D. candidate go into a third grade classroom and wonder why the students don’t understand differential equations. Security is a big problem, and the kinds of things David is comfortable with at the top of his Pyramid of Pain would be lost on 98% of the world. If even 40% of the broad market would use IP blacklists more effectively, that would have a huge impact on security posture. The TTPs he discusses are so far beyond the capabilities of most companies that he is talking a different language. But that’s okay. As the TI market matures we will see better and more sophisticated use of information to improve defenses. Until then TI will largely be a marketing bandwagon everyone needs to jump on. – MR
Pandering from within: Rod Trent’s statement that use of cloud computing means corporate data that resides outside of control of IT puts the entire business at risk is an irresponsible assertion and a disservice to IT professionals. You don’t lose control of data by moving it to the cloud. How you deploy security in the cloud differs from what you need to do within your own data centers, and which capabilities are offered varies from vendor to vendor, but cloud services are no more or less inherently secure than your own hardware. As Chris Hoff said in his RSA presentation this year, “Security is more a function of your operational model than cloud vs. on-prem deployments; if your on-prem security sucks today, it’s likely your cloud security deployment will also suck.” Go figure. Cloud services imply engagement with a third party, so you will by definition need some level of trust in the provider, but you get to choose a provider and service delivery model you are comfortable with. Sweeping generalizations like “I’m not sold on the statement that the Cloud is ‘secure enough to use’” are simply ignorant assertions to prop up the author’s thinly veiled security appliance agenda. – AL
People? Process? Bah! Bejtlich gets pretty fired up as he pulls apart Dave Aitel’s post on the pros and cons of certain defensive technologies. Richard’s point is that “Network defense is more than tools and tactics. It’s more often about people and processes.” Amen to that, but we do need to use the tools out there because no human (or team of humans) can scale to the extent of the problem any more. So you need to be very clear about the capabilities – and more importantly limitations – of the tools you will use to defend yourself. Richard’s real point is the need for a programmatic approach to security. Even people and processes must be brought to bear in the same manner as tools and technologies: as part of an integrated security program. – MR
When bad security is not an option: This week we saw about 12.3% of the BTC on Poloniex was stolen, which is shortly after Mt. Gox was shuttered indefinitely. It’s early days for Bitcoin, and this instability has little to do with the viability of Bitcoin as a currency – more sloppy execution by exchanges and services, and failure to protect their systems. These are new companies with shiny new applications, and they will continue to lose bitcoins until they shake out bugs and learn lessons that banks and traditional financial houses have learned over centuries. In the case of Poloniex, it was an attack on application business logic. Hopefully most of these exchanges will take note and hire professionals to come in for threat modeling and penetration testing, to find flaws before attackers. It’s not like they don’t have genuine financial incentive to be secure. If not money will continue to disappear. – AL
Where the humans at? I have never been a fan of highly probabilistic models of risk or vulnerability. They typically involve assumptions on top of assumptions, and that usually leads to faulty decision making. My quant friends argue constantly that I’m being obtuse, and analysis in the right context can assist in decision making. They are probably right. Russell Thomas has been putting forth models for a while to help provide this context. Lately he has gotten into a little discussion (and yes, I’m being kind) about the role of probability in making security decisions. The reality is that at some point someone has to make a decisions about what to do. You want to feel good about that decision. That could involve prayer, it could involve a hard-core model, or it could involve experience – or more likely all of the above. If you can believe the math, I have no issue with models. Given the amount of data we are all dealing with, you need some way to reduce it and make sense of it, and that will involve probabilities in some way, shape, or form. But security is not high-velocity trading. The models have limitations, and I am not about to trade a 20-year security analyst for a risk model any time soon. And I don’t think Russell is either. – MR
Posted at Wednesday 5th March 2014 12:00 am
(0) Comments •
By Adrian Lane
I have had many conversations over the last few months with firms about to take their first plunge into Agile development methodologies. Each time they ask how to map secure software development processes into an Agile framework. So I picked this Firestarter for today’s retrospective on Agile Development and Security (see the original post with comments).
I am a big fan of the Agile project development methodology, especially Agile with Scrum. I love the granularity and focus it requires. I love that at any given point in time you are working on the most important feature or function. I love the derivative value of communication and subtle peer pressure that Scrum meetings produce. I love that if mistakes are made, you do not go far in the wrong direction – resulting in higher productivity and few total disasters. I think Agile is the biggest advancement in code development in the last decade because it addresses issues of complexity, scalability, focus, and bureaucratic overhead.
But it comes with one huge caveat: Agile hurts secure code development. There, I said it. Someone had to. The Agile process, and even the scrum leadership model, hamstrings development in terms of building secure products. Security is not a freakin’ task card. Logic flaws are not well-documented and discreet tasks to be assigned. Project managers (and unfortunately most ScrumMasters) learned security by skimming a “For Dummies” book at Barnes & Noble while waiting for lattes, but they are the folks making the choices as to what security should make it into iterations. Just like general IT security, we end up wrapping the Agile process in a security blanket or bolting on security after the code is complete, because the process itself is not suited to secure development.
I know several of you will be saying “Prove it! Show us a study or research evidence that supports your theory.” I can’t. I don’t have meaningful statistical data to back up my claim. But that does not mean it isn’t true, and there is ample anecdotal evidence to support what I am saying. For example:
- The average Sprint duration of two weeks is simply too short for meaningful security testing. Fuzzing & black box testing are infeasible in the context of nightly builds or pre-release sanity checks.
- Trust assumptions, between code modules or system functions where multiple modules process requests, cannot be fully exercised and tested within the Agile timeline. White box testing can be effective, but security assessments simply don’t fit into neat 4-8 hour windows.
- In the same way Agile products deviate from design and architecture specifications, they deviate from systemic analysis of trust and code dependencies. It is a classic forest for the trees problem: efficiency and focus gained by skipping over big picture details necessarily come at the expense of understanding how the system and data are used as a whole.
- Agile is great for dividing and conquering what you know, but not so great for dealing with the abstract. Secure code development is not like fixing bugs where you have a stack trace to follow. Secure code development is more about coding principles that lead to better security. In the same way Agile cannot help enforce code ‘style’, it doesn’t help with secure coding guidelines. (Secure) style verification is an advantage of peer programming and inherent to code review, but not intrinsic to Agile.
- The person on the Scrum team with the least knowledge of security, the Product Manager, prioritizes what gets done. Project managers generally do not track security testing, and they are not incented to get security right. They are incented to get the software over the finish line. If they track bugs on the product backlog, they probably have a task card buried somewhere but do not understand the threats. Security personnel are chickens in the project, and do not gate code acceptance the way they traditionally were able in waterfall testing; they may also have limited exposure to developers.
- The fact that major software development organizations are modifying or wrapping Agile with other frameworks to compensate provide security is evidence of the difficulties in applying security practices directly.
The forms of testing that fit Agile development are more likely to get done. If they don’t fit they are typically skipped (especially at crunch time), or they need to be scheduled outside the development cycle. It’s not just that the granular focus on tasks makes it harder to verify security at the code and system levels. It’s not just that features are the focus, or that the wrong person is making security decisions. It’s not just that the quick turnaround in code production precludes effective forms of testing for security. It’s not just that it’s hard to bucket security into discreet tasks. It is all that and more.
We are not about to see a study comparing Waterfall with Agile for security benefits. Putting together similar development teams to create similar products under two development methodologies to prove this point is infeasible. I have run Agile and Waterfall projects of similar natures in parallel, and while Agile had overwhelming advantages in a number of areas, security was not one of them. If you are moving to Agile, great – but you will need to evolve your Agile process to accommodate security.
What do you think? How have you successfully integrated secure coding practices with Agile?
Posted at Friday 28th February 2014 9:00 am
(3) Comments •
By Mike Rothman
Since we’re getting all nostalgic and stuff, I figured I’d dust off the rationale I posted the day we announced that I was joining Securosis. That was over 4 years ago and it has been a great ride. Rich and Adrian haven’t seen fit to fire me for cause yet, and I think we’ve done some great work.
Of course the plans you make typically aren’t worth the paper they’re written on. We have struggled to launch that mid-market research offering. And we certainly couldn’t have expected the growth we have seen with our published research (using our unique Totally Transparent Research process) or our retainer business. So on balance it’s still all good.
By the way, I still don’t care about an exit, as I mentioned in the piece below. I am having way too much fun doing what I love. How many folks really get to say that? So we will continue to take it one day at a time, and one research project at a time. We will try new stuff because we’re tinkerers. We will get some things wrong, and then we’ll adapt. And we’ll drink some beer. Mostly because we can…
The Pope Visits Security Incite + Securosis
(Originally published on the Security Incite blog – Jan 4, 2010.)
When I joined eIQ, I did a “POPE” analysis on the opportunity, to provide a detailed perspective on why I made the move. The structure of that analysis was pretty well received, so as I make another huge move, I may as well dust off the POPE and use that metaphor to explain why I’m merging Security Incite with Securosis.
Analyzing every “job” starts with the people. I liked the freedom of working solo, but ultimately I knew that model was inherently limiting. So thinking about the kind of folks I’d want to work with, a couple of attributes bubbled to the top. First, they need to be smart. Smart enough to know when I’m full of crap. They also need to be credible. Meaning I respect their positions and their ability to defend them, so when they tell me I’m full of crap – I’m likely to believe them. Any productive research environment must be built on mutual respect.
Most importantly, they need to stay on an even keel. Being a pretty excitable type (really!), when around other excitable types the worst part of my personality surfaces. Yet, when I’m around guys that go with the flow, I’m able to regulate my emotions more effectively. As I’ve been working long and hard on personal development, I didn’t want to set myself back by working with the wrong folks.
For those of you that know Rich and Adrian, you know they are smart and credible. They build things and they break them. They’ve both forgotten more about security than most folks have ever known. Both have been around the block, screwed up a bunch of stuff and lived to tell the story.
And best of all, they are great guys. Guys you can sit around and drink beer with. Guys you looking forward to rolling your sleeves up with and getting some stuff done. Exactly the kind of guys I wanted to work with.
Securosis will be rolling out a set of information products targeted at accelerating the success of mid-market security and IT professionals. Let’s just say the security guy/gal in a mid-market company may be the worst job in IT. They have many of the same problems as larger enterprises, but no resources or budget. Yeah, this presents a huge opportunity.
We also plan to give a lot back to the community. Securosis publishes all its primary research for free on the blog. We’ll continue to do that. So we have an opportunity to make a difference in the industry as well.
To be clear, the objective isn’t to displace Gartner or Forrester. We aren’t going to build a huge sales force. We will focus on adding value and helping to make our clients better at their jobs. If we can do that, everything else works itself out.
To date, no one has really successfully introduced a syndicated research product targeted to the mid-market, certainly not in security. That fact would scare some folks, but for me it’s a huge challenge. I know hundreds of thousands of companies struggle on a daily basis and need our help. So I’m excited to start figuring out how to get the products to them.
In terms of research capabilities, all you have to do is check out the Securosis Research Library to see the unbelievable productivity of Rich and Adrian. The library holds a tremendous amount of content and it’s top notch. As with every business trying something new, we’ll run into our share of difficulties – but generating useful content won’t be one of them.
Honestly, I don’t care about an exit. I’ve proven I can provide a very nice lifestyle for my family as an independent. That’s liberating, especially in this kind of economic environment. That doesn’t mean I question the size of the opportunity. Clearly we have a great opportunity to knock the cover off the ball and build a substantial company. But I’m not worried about that. I want to have fun, work with great guys and help our clients do their jobs better. If we do this correctly, there are no lack of research and media companies that will come knocking.
On the first working day of a new decade, I’m putting the experiences (and road rash) gained over last 10 years to use. Whether starting a business, screwing up all sorts of things, embracing my skills as an analyst or understanding the importance of balance in my life, this is the next logical step for me.
Looking back, the past 10 years have been very humbling. It started with me losing a fortune during the Internet bubble. selling the company I founded for the cash on our balance sheet because we couldn’t find enough customers. Trying to start two other companies – to no avail. Then getting fired (or laid off) three times. Quite a decade, eh?
Yet, I persevere. I lived through that and had lots of successes as well. Each of those experiences helped me get to this place and become ready to do this. And I’m ready. So hold on, it’s going to be a great ride.
Posted at Thursday 27th February 2014 5:00 am
(0) Comments •
As I was crawling through the old archives for some posts, I found my very first reference to Mike here at Securosis. I timed this Revisited post to fire off when Mike’s post on joining Securosis goes live, and the title now seems to have more meaning.
Off Topic: A Little Perspective
This has nothing to do with security other than the fact Mike Rothman is a security analyst.
Sometimes it’s worth sitting back and evaluating why you’re in the race in the first place. It’s all too easy to get caught up in the insanity of day-to-day demands or the incredibly deceptive priorities of the corporate and government rat races.
A few months ago I took a step back and decided to reduce travel, stay healthy, and start this blog. I wanted a more personal outlet for writing on topics and in a style that’s inappropriate at my day job (in other words, more fun). My challenge is running this site in a way that doesn’t create a conflict of interest with my employer, and thus I don’t publish anything here that I should be publishing there.
Mike just went off and started his own company to support his real priorities.
You should really read this.
Posted at Thursday 27th February 2014 4:59 am
(0) Comments •
After publishing this, I realized I should have taken more time editing, especially after Apple released their iOS Security paper this week. My intention was to refer to situations where, often due to attacks, vulnerabilities, or other events, Apple is pushed into responding. They can still struggle to balance the lines between what they want to say, and what outsiders want to hear. They have very much improved communications with researchers, the media, and the level of security information they publish in the open. It is the crisis situations that knock things off kilter at times.
I am sometimes called an Apple apologist for frequently defending their security choices, but it wasn’t always that way. I first started writing about Apple security because those were the products I used, and I was worried Apple didn’t take security seriously. I was very personally invested in their choices, and there were a lot of reasons when I first posted this back in 2006 to think we were headed for disaster.
In retrospect, my post was both on and off target. I thought at the time that Apple needed to focus more on communications. But Apple, as always, chose their own path. They have improved communications significantly, but not nearly as much as someone like Microsoft. But at the same time they tripled down on security. iOS is now one of the most secure platforms out there (yes, even despite the patch last week). OS X is also far more secure than it was, and Apple continues to invest in new security options for users.
I was right and I was wrong. Apple recognized, due to the massive popularity of iOS, that building customer trust was essential to maintaining a market lead. They acted on that with dramatic improvements in security. iOS has yet to suffer any major wide-scale exploitation. OS X added features like FileVault 2 (encryption for the masses) and GateKeeper (wrecking malware markets). Apple most definitely sees security as essential to trust. But they still struggle with communications. Not that I expect them to ever not act like Apple, but they are still feeling their way around the lines to find a level they are comfortable with culturally, which still avoids negative spin cycles like I talk about below.
This post originally appeared on October 18, 2006
Apple, Security, and Trust
Before I delve into this topic I’d like to remind readers that I’m a Mac user and Apple fan. We are a 2 person, 2 Mac, 3 iPod, 2 Airport Express household, with another Mac in the plans this spring. By the same token I don’t think Microsoft is evil and consider some of their products to be quite good. That said I prefer OS X and have no plans to switch to Vista, although I’ll probably run it in a virtual machine on my Mac.
What I’m about to say is in the nature of protecting, not attacking, one of my favorite vendors. Apple faces a choice. Down one path is the erosion of trust, lost opportunities, and customers facing increased risk. On the other path is increased trust, greater opportunities, and happy, safe, customers. I have a lot vested in Apple, and I’d like to keep it that way.
As most of you probably know by now, Apple shipped a limited number of video iPods loaded with a Windows virus that could infect an attached PC. The virus is well known and all antivirus software should stop it, but the reality is this is an extremely serious security failure on the part of Apple. The numbers are small and damages limited, but there was obviously some serious breakdown in their security controls and QA process.
As with many recent Apple security stories this one was about to quietly fade into the night were it not for Apple PR. In Apple’s statement they said, “As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it.”. As covered by George Ou and Amrit Williams, this statement is embarrassing, childish, and irresponsible. It’s the technical equivalent of blaming a crime victim for their own victimization. I’m not defending the security problems of XP, which are a serious epidemic unto themselves, but this particular mistake was Apple’s fault, and easily preventable.
While Mike Rothman agrees with Ou and Williams, he correctly notes that this is just Apple staying on message. That message, incorporated into all major advertising and marketing, is that Macs are more secure and if you’d just switch to a Mac you wouldn’t have to worry about spyware and viruses.
It’s a good message, today, because it’s true. I bought my mom a Mac and talked my sister into switching her small business to Macs primarily because of security. I’m overprotective and no longer feel my friends and family can survive on the Internet on XP. Vista is a whole different animal, fundamentally more secure than its predecessors, but it’s not available yet so I couldn’t consider that option. Thus it was iMac and Mac mini city.
But when Apple sticks to this message in the face of a contradictory reality they expose themselves, and their customers, to greater risks. Reality is starting to change and Apple isn’t, and therein lies my concern.
All relationships are founded on trust and need. (Amrit has another good post on this topic in business relationships). One of the keystones of trust is security. I like to break trust into three components:
- Intent: How do you intend to treat participants in a relationship?
- Capability: Can you behave in compliance with your intent?
- Communication: Can you effectively communicate both your intent and capability?
Since there’s no perfect security we always need to make security tradeoffs. Intent decides how far you need to go with security, while capability defines if you’re really that secure, and communication is how you get customers to believe both your intent and capability.
Recent actions by Apple are breaking their foundations of trust. As a business this is a critical issue; Apple relies heavily on trust to grow their market. Trust that their products work well, are simple to use, include superior capabilities, and are more secure. Apple’s message is that Macs are secure, simple, elegant, and reliable. Safe and secure is a powerful message, one that I suspect (based on personal experience) drives many switchers. When I told my cab driver today that Macs have no spyware or active viruses he was stunned.
Should Apple lose either their intent to provide superior security, their capability to achieve security, or their ability to communicate either of those, they face reasonable risk of losing customers, or at least growth opportunities. Security, today, is one of Apple’s cornerstones. Anything that erodes it increases their business risks.
At the same time, should communication disconnect from either intent or capability, Apple places then places both their trust relationship, and their customers, at risk. Take my favorite snake-oil salesmen at Diebold- by having no intent to secure their products and no security capabilities in their products, and communicating that the products are secure, they create huge potential for security failures. Less educated customers buy products thinking they’re secure, but the products are so flawed it places these customers (the voting public) at extreme risk. Software vendors have done this in the past – claiming products are secure and covering up failures in the hopes the customers and prospects won’t notice.
Recent events indicate that Apple may stay on an impossible message (perfect security) and face failures in capability despite the best intent. The entire Black Hat debacle showed Apple pushing the message so hard that the debate lived far longer than needed, exposing more of the public to a potential security failure than would have otherwise noticed, drawing the attention of researchers who may now want to prove Apple isn’t invincible, and losing the trust of some of us in the industry disappointed by PR’s management of the incident.
The iPod virus infections shows a lack of capability (security QA in shipping products) and poor communications (failure to take full responsibility). It’s a very small problem, but their arrogant approach to spinning the story lead me to question how they might respond to more serious issues. We have, over the course of a couple months, two incidents where Apple decided to play the PR game rather than taking responsibility and communicating openly. I realize those of you that still believe the wifi hack was BS probably believe Apple dealt with the situation reasonably, but for reasons I can’t disclose I still think PR overrode good security practices.
The latest security updates indicate that OS X, while still materially more secure than XP, has its own fair share of flaws. We’ve seen zero day vulnerabilities in Safari, multiple holes in QuickTime, wireless vulnerabilities, and even a flaw that could allow a specially crafted image sent in email to exploit and own your Mac. The first time Microsoft patched an image vulnerability like that I spammed all my friends and family to update their computers pronto. Macs are pretty secure, but not invulnerable, and fortunately we’ve managed to avoid any significant mass exploits. I’d really like that trend to continue.
Let’s look back on the three components of trust. Right now I believe Apple still intends to keep us secure; of that I have little doubt. The next release of the operating system should be very telling – should they adopt some more advanced OS security features, like memory randomization (a very cool feature of Vista) it will indicate they continue to push towards a secure OS. So far they’ve done pretty well. Next is communication, which is a mixed bag. On one hand, the message is clear and unambiguous – Macs are secure. On the other hand is their arrogance, as best illustrated in the response to the iPod virus and the wifi vulnerability. Those are early indications that the message could exceed reality, eventually (probably) leading to an erosion of trust.
The linchpin is capability. As I already stated – OS X is materially more secure than Windows XP, but is far from perfect. We’ll eventually see a mass exploit (I hope I’m wrong). Recent vulnerability disclosures by Apple themselves indicate that the kinds of serious flaws that lead to worms and viruses can exist in OS X. We also shouldn’t underestimate the impact of goodwill towards Apple on exploit development – researchers and attackers tend to focus on hot issues (just look at the recent spate of Microsoft Office exploits). If you piss off the bad guys, or just the generally good social malcontents, eventually they’ll come after you. Anyone still think Oracle is unbreakable?
Thus Apple stands at a crossroads. Should they choose the marketing line they’d better be able to back it up. If you base your reputation on security, and that security is eroded, trust is equally eroded. If they communicate more openly and honestly about security, communications will reinforce intent and capability and even imperfect security will be accepted by the market. If they intend to deceive the market (the one option I don’t think they’ll take) it will place customers at risk and eventually destroy trust.
I’ve trusted Apple. I’d like that trust to continue. But incidents like the wifi flaw and the iPod virus are starting to weaken that relationship. Not because Apple made mistakes and vulnerabilities and flaws made it into products, but because Apple mangled the communications and lead me to believe image was more important than substance and accountability.
When capability, intent, and communications are aligned, trust is reinforced. If any of those degrade or deviate from reality, trust disappears, customers are in danger, and Apple’s business is at risk.
It’s early. Opportunities are still open. The roads are clear. If Apple is open and honest, and harbors good, intentions they’ll succeed. I really REALLY don’t want to see them go the way of other vendors who put PR in charge of security.
Posted at Wednesday 26th February 2014 12:22 pm
(0) Comments •
By Adrian Lane
We are running a retrospective during RSA because we cannot blog at the show. We each picked a couple posts we like and still think relevant enough to share. I picked a 2011 post on Hammers and Homomorphic Encryption, because a couple times a year I hear about a new startup which is going to revolutionize security with a new take on homomorphic encryption. Over and over. And perhaps some day we will get there, but for now we have proven technologies that work to the same end. (Original post with comments)
Researchers at Microsoft are presenting a prototype of encrypted data which can be used without decrypting. Called homomorphic encryption, the idea is to keep data in a protected state (encrypted) yet still useful. It may sound like Star Trek technobabble, but this is a real working prototype. The set of operations you can perform on encrypted data is limited to a few things like addition and multiplication, but most analytics systems are limited as well. If this works, it would offer a new way to approach data security for publicly available systems.
The research team is looking for a way to reduce encryption operations, as they are computationally expensive – their encryption and decryption demand a lot of processing cycles. Performing calculations and updates on large data sets becomes very expensive, as you must decrypt the data set, find the data you are interested in, make your changes, and then re-encrypt altered items. The ultimate performance impact varies with the storage system and method of encryption, but overhead and latency might typically range from 2x-10x compared to unencrypted operations. It would be a major advancement if they could dispense away with the encryption and decryption operations, while still enabling reporting on secured data sets.
The promise of homomorphic encryption is predictable alteration without decryption. The possibility of being able to modify data without sacrificing security is compelling. Running basic operations on encrypted data might remove the threat of exposing data in the event of a system breach or user carelessness. And given that every company even thinking about cloud adoption is looking at data encryption and key management deployment options, there is plenty of interest in this type of encryption.
But like a lot of theoretical lab work, practicality has an ugly way of pouring water on our security dreams. There are three very real problems for homomorphic encryption and computation systems:
- Data integrity: Homomorphic encryption does not protect data from alteration. If I can add, multiply, or change a data entry without access to the owner’s key: that becomes an avenue for an attacker to corrupt the database. Alteration of pricing tables, user attributes, stock prices, or other information stored in a database is just as damaging as leaking information. An attacker might not know what the original data values were, but that’s not enough to provide security.
- Data confidentiality: Homomorphic encryption can leak information. If I can add two values together and come up with a consistent value, it’s possible to reverse engineer the values. The beauty of encryption is that when you make a very minor change to the ciphertext – the data you are encrypting – you get radically different output. With CBC variants of encryption, the same plaintext has different encrypted values. The question with homomorphic encryption is whether it can be used while still maintaining confidentiality – it might well leak data to determined attackers.
- Performance: Performance is poor and will likely remain no better than classical encryption. As homomorphic performance improves, so do more common forms of encryption. This is important when considering the cloud as a motivator for this technology, as acknowledged by the researchers. Many firms are looking to “The Cloud” not just for elastic pay-as-you-go services, but also as a cost-effective tool for handling very large databases. As databases grow, the performance impact grows in a super-linear way – layering on a security tool with poor performance is a non-starter.
Not to be a total buzzkill, but I wanted to point out that there are practical alternatives that work today. For example, data masking obfuscates data but allows computational analytics. Masking can be done in such a way as to retain aggregate values while masking individual data elements. Masking – like encryption – can be poorly implemented, enabling the original data to be reverse engineered. But good masking implementations keep data secure, perform well, and facilitate reporting and analytics. Also consider the value of private clouds on public infrastructure. In one of the many possible deployment models, data is locked into a cloud as a black box, and only approved programatic elements ever touch the data – not users. You import data and run reports, but do not allow direct access the data. As long as you protect the management and programmatic interfaces, the data remains secure.
There is no reason to look for isolinear plasma converters or quantum flux capacitors when when a hammer and some duct tape will do.
Posted at Wednesday 26th February 2014 8:30 am
(0) Comments •
Wow! Sometimes we find things in the archives that still really resonate. This is a short one but I’ll be damned if I don’t expect to see this exact phrase used on the show floor at RSA this week.
This was posted September 25, 2006. I guess some things never change…
How to Smell Security Snake Oil in One Sentence or Less
If someone ever tells you something like the following:
“We defend against all zero day attacks using a holistic solution that integrates the end-to-end synergies in security infrastructure with no false positives.”
Posted at Tuesday 25th February 2014 12:13 pm
(0) Comments •
This paper originally started with a blog post called Inflection. Sure, many of our papers start as a series of posts, but this time the post came long before I thought of a paper. I started seeing a bunch of interrelated trends, and what appeared to be some likely unavoidable outcomes. Unlike most predictive pieces, I focused as much on inherent security trends as on disruptive forces. Less “new attacks” and more “new ways we are doing things”.
The research continued, but I never expected a chance to write it up as a paper.
Out of nowhere the folks at Box contacted me to see if I had an interest in writing up and licensing something on where security is headed. I pointed them toward Inflection, and it hit exactly what they were looking for. So I got a chance to pull together the additional research I have been thinking about since that post back in 2012, and compile everything into a paper. As an analyst it isn’t often I get a chance to focus on far-field research, so I am excited to get this one out the door.
This paper is also being co-released by the Cloud Security Alliance, who reviewed and approved its findings.
I hope you find it useful, and please keep in mind that everything I discuss is in practice someplace today, but I expect it to take ten or more years for these practices to become widespread and their full implications to kick in.
Posted at Tuesday 25th February 2014 8:00 am
(0) Comments •
By Mike Rothman
As we continue our journey down memory lane I want to take a look at what I said about the RSA/NetWitness deal back in April 2011, when it was announced. In hindsight the NetWitness technology has become the underlying foundation of RSA’s security management and security analytics offerings, so I underplayed that a bit. EnVision is pretty much dead. And we haven’t really seen a compelling alternative on the full packet capture and analytics front. Although a bunch of bigger SIEM players started introducing that technology this year.
As with most everything, some prognostications were good and some not so good. And if I had a crystal ball that worked I would have invested in WhatsApp, rather than trying to figure out the future of security.
Fool us once… EMC/RSA Buys NetWitness
(Published on the Securosis blog April 4, 2011)
To no one’s surprise (after NetworkWorld spilled the beans two weeks ago), RSA/EMC formalized its acquisition of NetWitness. I guess they don’t want to get fooled again the next time an APT comes to visit. Kidding aside, we have long been big fans of full packet capture, and believe it’s a critical technology moving forward. On that basis alone, this deal looks good for RSA/EMC.
APT, of course. Isn’t that the rationale for everything nowadays? Yes, that’s a bit tongue in cheek (okay, a lot) but for a long time we have been saying that you can’t stop a determined attacker, so you need to focus on reacting faster and better. The reality remains that the faster you figure out what happened and remediate (as much as you can), the more effectively you contain the damage. NetWitness gear helps organizations do that. We should also tip our collective hats to Amit Yoran and the rest of the NetWitness team for a big economic win, though we don’t know for sure how big a win. NetWitness was early into this market and did pretty much all the heavy lifting to establish the need, stand up an enterprise class solution, and show the value within a real attack context.
They also showed that having a llama at a conference party can work for lead generation. We can’t minimize the effect that will have on trade shows moving forward.
So how does this help EMC/RSA? First of all, full packet capture solves a serious problem for obvious targets of determined attackers. Regardless of whether the attack was a targeted phish/Adobe 0-day or Stuxnet type, you need to be able to figure out what happened, and having the actual network traffic helps the forensics guys put the pieces together. Large enterprises and governments have figured this out and we expect them to buy more of this gear this year than last. Probably a lot more. So EMC/RSA is buying into a rapidly growing market early.
But that’s not all. There is a decent amount of synergy with the rest of RSA’s security management offerings. Though you may hear some SIEM vendors pounding their chests as a result of this deal, NetWitness is not SIEM. Full packet capture may do some of the same things (including alert on possible attacks), but it analysis is based on what’s in the network traffic – not logs and events. More to the point, the technologies are complimentary – most customers pump NetWitness alerts into a SIEM for deeper correlation with other data sources. Additionally some of NetWitness’ new visualization and malware analysis capabilities supplement the analysis you can do with SIEM. Not coincidentally, this is how RSA positioned the deal in the release, with NetWitness and EnVision data being sent over to Archer for GRC (whatever that means).
Speaking of EnVision, this deal may take some of the pressure off that debacle. Customers now have a new shiny object to look at, while maybe focusing a little less on moving off the RSA log aggregation platform. It’s no secret that RSA is working on the next generation of the technology, and being able to offer NetWitness to unhappy EnVision customers may stop the bleeding until the next version ships.
A side benefit is that the sheer amount of network traffic to store will drive some back-end storage sales as well. For now, NetWitness is a stand-alone platform. But it wouldn’t be too much of a stretch to see some storage/archival integration with EMC products. EMC wouldn’t buy technology like NetWitness just to drive more storage demand, but it won’t hurt.
Too Little, Too Late (to Stop the Breach)
Lots of folks drew the wrong conclusion, that RSA bought NetWitness because of their recent breach. But these deals doesn’t happen overnight, so this acquisition has been in the works for quite a while. But what could better justify buying a technology than helping to detect a major breach? I’m sure EMC is pretty happy to control that technology. The trolls and haters focus on the fact that the breach still happened, so the technology couldn’t work that well, right?
Actually, the biggest issue is that EMC didn’t have enough NetWitness throughout their environment. They might have caught the breach earlier if they had the technology more widely deployed. Then again, maybe not, because you never know how effective any control will be at any given time against any particular attack, but EMC/RSA can definitely make the case that they could have reacted faster if they had NetWitness everywhere. And now they likely will.
The full packet capture market is still very young. There are only a handful of direct competitors to NetWitness, all of whom should see their valuations skyrocket as a result of this deal. Folks like Solera Networks are likely grinning from ear to ear today. We also expect a number of folks in adjacent businesses (such as SIEM) to start dipping their toes into this water.
Speaking of SIEM, NetWitness did have partnerships with the major SIEM providers to send them data, and this deal is unlikely to change much in the short term. But we expect to see a lot more integration down the road between NetWitness, EnVision Next, and Archer, which could create a competitive wedge for RSA/EMC in large enterprises. So we expect the big SIEM players to either buy or build this capability over the next 18 months to keep pace. Not that they aren’t all over the APT marketing already.
This is a good deal for RSA/EMC – acquiring NetWitness provides a strong, differentiated technology in what we believe will be an important emerging market. But with RSA’s mixed results in leveraging acquired technology, it’s not clear that they will remain the leader in two years. But if they provide some level of real integration in that timeframe, they will have a very compelling set of products for security/compliance management.
This is also a good deal for both NetWitness and RSA customers. The product is now too high-profile for RSA to muck with it and decrease its value, as happens with all too many acquisitions. There are some potentially interesting integration opportunities, and the product will hum along nicely for those who are happy with current capabilities and the usual improvements over time.
It isn’t often we get to say nice things about a security deal, but this one is a slam dunk.
Posted at Tuesday 25th February 2014 5:00 am
(0) Comments •
This has always been one of my favorite posts, and it is one I still use regularly. I even have a slide on it in my RSA presentation for this week.
The triangle still guides a lot of my thinking on data security. I am also now starting to think in terms of workload security, about which you will be hearing more soon. In this age of increased focus on egress filtering and incident response, I think the triangle does a good job of capturing a direction many security professionals realize we need to head.
I originally posted this May 12, 2009.
The Data Breach Triangle
I’d like to say I first became familiar with fire science back when I was in the Boulder County Fire Academy, but it really all started back in the Boy Scouts. One of the first things you learn when you’re tasked with starting, or stopping, fires is something known as the fire triangle. Fire is a pretty fascinating process when you dig into it. It demonstrates many of the characteristics of life (consumption, reproduction, waste production, movement), but is just a nifty chemical reaction that’s all sorts of fun when you’re a kid with white gas and a lighter (sorry Mom). The fire triangle is a simple model used to describe the elements required for fire to exist: heat, fuel, and oxygen. Take away any of the three, and fire can’t exist. (In recent years the triangle was updated to a tetrahedron, but since that would ruin my point, I’m ignoring it). In wildland fires we create backburns to remove fuel, in structure fires we use water to remove heat, and with fuel fires we use chemical agents to remove oxygen.
With all the recent breaches, I came up with the idea of a Data Breach Triangle to help prioritize security controls. The idea is that, just like fire, a breach needs three elements. Remove any of them and the breach is prevented. It consists of:
- Data: The equivalent of fuel – information to steal or misuse.
- Exploit: The combination of a vulnerability and/or an exploit path to allow an attacker unapproved access to the data.
- Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive.
Our security controls should map to the triangle, and technically only one side needs to be broken to prevent a breach. For example, encryption or data masking removes the data (depending a lot on the encryption implementation). Patch management and proactive controls prevent exploits. Egress filtering or portable device control prevents egress. This assumes, of course, that these controls actually work – which we all know isn’t always the case.
When evaluating data security I like to look for the triangle – will the controls in question really prevent the breach? That’s why, for example, I’m a huge fan of DLP content discovery for data cleansing – you get to ignore a whole big chunk of expensive security controls if there’s no data to steal. For high-value networks, egress filtering is a key control if you can’t remove the data or absolutely prevent exploits (exploits being the toughest part of the triangle to manage).
The nice bit is that exploit management is usually our main focus, but breaking the other two sides is often cheaper and easier.
Posted at Monday 24th February 2014 12:32 pm
(2) Comments •
By Mike Rothman
All of us Securosis folks will be at the RSA Conference this week, so we figured we’d pre-load some old stuff to get a feel for how our research positions turned out. Mine is really old, digging back into the archives from when I had just started Security Incite. Each year I put together a set of Incites that reflected what I expected to happen that year.
I basically copied the idea (and format) from my META Group days, where each year we obsessed over our 12 META Trends. The idea was to come up with a paragraph for each of our main coverage areas and provide some guidance. No percentages or anything like that.
The innovation that I introduced was to actually go back later in the year and assess how well the projection worked out. We never did that at META. But I figured it would be a hoot to look back at what I thought was going to be big in 2006, so here are the Incites and some more tactical predictions. Some stuff was good. Some stuff was, um, not so good. At least it should provide some laughs.
And if you want to check out the grades I gave myself on each Incite a year later, check out my 2006 report card. I can tell you my predictions stunk very badly.
You can also check out the 2007 report card while you’re at it, which will ensure you never ask me to prognosticate about anything…
2006 Incites and Predictions
(These originally appeared on the Security Incite blog, Jan 9, 2006.)
What are the Security Incites?
Annually, Security Incite will publish a list of the key “trends” and expectations in the security business for the next year. Called “Security Incites” and written from the perspective of the end user (or security consumer), Incites provide direction on what to expect, assisting the decision making process as budgets and technology adoption plans are finalized for the upcoming year. Each Incite provides a clear position and distills the impact on buying dynamics and architectural constructs. Incites also set the stage for Security Incite’s upcoming research agenda.
What’s the difference between a “Security Incite” and a “Prediction?”
Predictions are things we expect to happen within the next 12 months, and tend to be more event-oriented. The Security Incites provide a broader perspective across the security domains and can take a longer than 12 months view.
1. No Mas Box (Less Boxes, More Functionality)
Users will increasingly revolt about adding yet another narrowly focused security appliance into their network and actively examine new “simplification” architectures. New Unified Threat Management (UTM) products, using blade servers and virtualization technologies, appear in 2006 putting vendors that license key intellectual property at a disadvantage. Management of the integrated UTM environment will remain difficult through 2007.
2. Get the NAC!
The increasing number of ingress points into corporate networks (mobile, contractors, VPN) forces users to migrate to a virtual network infrastructure with a secure net and an unsecured net. Network Admission Control (NAC) architectures gain traction in 2006 to facilitate this architectural construct, but do require homogeneity of equipment pushing the pendulum away from best of breed providers.
3. Who are you?
Identity Management (IDM) breaks out in 2006, as ROI-driven password management and single sign-on (SSO) initiatives are deployed en masse. Smart users increasingly figure out that strong and centralized IDM provides “good enough” authentication and authorization for compliance purposes, accelerating market growth in 2H 2006. Yet, identity federation continues to lag in a cloud of useless vendor bickering and standards immaturity until mid-2007. Token-based authentication finally hits the wall, as passwords remain good enough and no compelling alternative appears.
4. Stay Out of Jail
Compliance continues to generate tremendous hype, but largely remains a red herring throughout 2006. Smart users will use the compliance word to get funding for critical imperatives (perimeter redesign, identity management) and sufficiently document their processes to keep regulators happy. Those not so smart users figure encryption is a panacea and buy some; ultimately realizing making encryption work on a large scale basis hasn’t gotten any easier.
5. Losing The Religion
Everyone finally realizes in 2006 that regardless of technical approach (IDS vs. IPS vs. firewalls vs. anomaly detection) it’s all about detecting and blocking malware quickly and effectively. Users expect to see multiple techniques implemented, spurring another wave of consolidation as vendors look to bring complete enterprise-class UTM solutions to market.
6. Endpoint Hostile Takeover
Driven by the prevalence of unwanted applications, internal zombies outbreaks, and documented information leaks enabled by key loggers and spyware, users will increasingly lock down endpoint devices, despite pushback from the business users. Limitations of the Windows XP security model makes lockdown difficult in 2006, but much easier when Microsoft’s Vista operating system is ready for deployment beginning in 2007.
7. Bad Content is Bad Content
Given “innovation” by spammers and fraudsters, keeping content filtering algorithms accurate and timely is proving very difficult for content-focused security vendors. In 2006, heuristics-based detection cocktails fall out of favor, pushing the pendulum back towards signatures that favor entrenched AV vendors. Users increasingly embrace “in the cloud” content filtering for e-mail, IM, and web traffic because it allows them to get rid of another box in the perimeter and stop worrying about exponentially increasing message volumes.
8. Security Management (oxy)Moron
Stand-alone security information management (SIM) plateaus in 2006, as consolidation continues and the need for large-scale system integration makes acceptable “time to value” out of reach for all but the largest enterprises. Closed correlation systems increasingly take root as users swing towards homogeneity and ratchet back expectations on which devices really need to be integrated into the management system, while leveraging the reporting infrastructure for compliance purposes.
Managed Security Services provide increasing value in terms of both operational capabilities and content filtering. Users realize that removing threats “in the cloud” provides better bang for the buck for mature technologies (firewalls, IPS, anti-spam, gateway AV, web filtering). The biggest challenge in 2006 will be integrating operational and reporting capabilities across internal and MSS spheres of control.
10. Built to Last (Securely)
As application security functions are further integrated into UTM platforms in 2006, focus shifts to actually building software securely. The high tech vertical will lead the way in embracing behavioral changes for developers, source code analysis tools, and techniques to protect data at rest. New Web 2.0, SOA and on-demand application architectures with better security models increase in importance.
11. It’s Time for “Stupidity School”
Though distasteful, security professionals will be forced to undertake a structured and comprehensive education program to stop employees from doing stupid things. Given the sophistication of attacks and the difficulty in stopping them at the perimeter, educated personnel may be the only defense.
12. Battle of the Titans
The big will continue to get bigger in 2006, as frenetic consolidation continues as product line breadth outweighs actually functionality. By the end of 2006, it becomes apparent that the real battle is between Cisco and Microsoft to control the architecture of networks and applications moving forward. As with other huge “marketectures,” users are caught in the crossfire, but 2007 will see enough additional functionality for those embracing homogeneity to see a wave of infrastructure upgrades. Vendors not strongly aligned with one of the two titans face irrelevance by 2009.
(Note: I put my commentary from the report card in here because it’s hilarious…)
- M&A continues, with small deals to acquire innovative technology being most prevalent. No blockbuster security deals (> $500 million) will happen in 2006.
GRADE: F (maybe a triple F, if that’s possible)
EMC/RSA – $2.1 BILLION. IBM/ISS – $1.4 BILLION. Need I say more?
- Vendors relying on licensing OEM technology find a world of hurt, as important intellectual property is acquired and licensing terms become increasingly unattractive. The UTM blade architecture makes intellectual property valuable real estate and those with strong IP positions see higher value exits.
Not too good on this one either. Seems that Crossbeam and IronPort did OK in 2006 and lots of service providers (especially in the anti-spam space) don’t seem to have problems relying on OEM technology. IronPort did roll out their own anti-spam technology, but they license lots of other stuff.
- Microsoft has limited positive impact on security in 2006 (despite the introduction of OneCare), but the AV market is living on borrowed time. Integrated security and endpoint presence for enforcement provides a visible hook for MSFT to catch up to Google.
Microsoft did bring OneCare to market and their rebranded Forefront offerings are in beta. Are Symantec and McAfee taking on water yet? Nope. But it’s clear that stand-alone AV is dead and all of these desktop offerings are evolving into more endpoint security oriented suites. In terms of the Google hook, what the hell was I thinking? Microsoft continues to chase Google, but security isn’t the way they plan to catch up.
- Increasingly bigger VARs start flexing their muscles and make or break a number of vendors in 2006. Those “made” vendors get big M&A outcomes in 2006.
There was a decent amount of consolidation in the VAR community (FishNet bought SiegeWorks and True North), but it would be a stretch to think that these folks had any influence on making or breaking vendors. Clearly many of the new security start-ups are going 100% channel by design as the introduce their first product, but it’s more to eliminate the pain of transitioning later rather than trying to get a big VAR to make their business.
- Continued vulnerabilities in AV and spyware products attract the attention of tort lawyers who target AV companies after the resurgence of a well-known attack renders most SMBs defenseless. Larger enterprises with multiple layers of defense escape unharmed and point to the criticality of a layered defense strategy.
This didn’t happen, though there were plenty of problems with AV software. I guess the tort lawyers were too busy suing high tech companies over stock option grants. That being said, this is still a big exposure and it’s just a matter of time before we see this actually happen.
- Open source security stumbles in 2006, and the changing business models and decreasing effectiveness of Nessus, Snort, and MailAssassin are not well received. Service providers make significant investments to drive a future renaissance in open source UTM software, SIM, web filtering and encryption to dramatically reduce their cost to deliver MSS offerings.
This one is tough because there are folks that are questioning the value of open source in security circles. But this happened more from the standpoint of open source applications (like PHP), which was plagued with vulnerabilities and no one to fix them. Nessus and Snort remain “good enough” for the technical users.
Another thing we didn’t see much of was the service providers doing much of anything relative to security, except maybe buy something. Again, I do think this is something that will happen – but it’s a fools errand to try to pinpoint when.
Posted at Sunday 23rd February 2014 1:59 pm
(0) Comments •
This post doesn’t hold up that well, but it goes back to 2006 and the first couple weeks the site was up. And I think it is interesting to reflect on how my thinking has evolved, as well as the landscape around the analysis.
In 2006 the debate was all about full vs. responsible disclosure. While that still comes up from time to time, the debate has clearly shifted. Many bugs aren’t disclosed at all, now that there is a high-stakes market where researchers can support entire companies just discovering and selling bugs to governments and other bidders. The legal landscape and prosecutorial abuse of laws have pushed some researchers to keep things to themselves. The adoption of cloud services also changes things, requiring completely different risk assessment around bug discovery.
Some of what I wrote below is still relevant, and perhaps I should have picked something different for my first flashback, but I like digging into the archives and reflecting on something I wrote back when I was still with Gartner, wasn’t even thinking about Securosis as more than a blog, and was in a very different place in my life (i.e., no kids).
Also, this is a heck of an excuse to include a screenshot of what the site looked like back then.
The 3 Dirty Little Secrets of Disclosure No One Wants to Talk About
As a child one of the first signs of my budding geekness was a strange interest in professional “lingo”. Maybe it was an odd side effect of learning to walk at a volunteer ambulance headquarters in Jersey. Who knows what debilitating effects I suffered due to extended childhood exposure to radon, the air imbued with the random chemicals endemic to Jersey, and the staccato language of the early Emergency Medical Technicians whose ranks I would feel compelled to join later in life.
But this interest wasn’t limited to the realm of lights and sirens; it extended to professional subcultures ranging from emergency services, to astronauts, to the military, to professional photographers. As I aged and even joined some of these groups I continued to relish the mechanical patois reserved for those earning expertise in a domain.
Lingo is often a compression of language; a tool for condensing vast knowledge or concepts into a sound byte easily communicated to a trained recipient, slicing through the restrictive ambiguity of generic language. But lingo is also used as a tool of exclusion or to mask complexity. The world of technology in general, and information security in particular, is as guilty of lingo abuse as any doctor, lawyer, or sanitation specialist.
Nowhere is this more apparent than in our discussions of “Disclosure”. A simple term evoking religious fervor among hackers, dread among vendors, and misunderstanding among normal citizens and the media who wonder if it’s just a euphemism for online dating (now with photos!).
Disclosure is a complex issue worthy of full treatment; but today I’m going to focus on just 3 dirty little secrets. I’ll cut through the lingo to focus on the three problems of disclosure that I believe create most of the complexity. After the jump that is…
“Disclosure” is a bizarre process nearly unique to the world of information technology. For those of you not in the industry, “disclosure” is the term we use to describe the process of releasing information about vulnerabilities (flaws in software and hardware that attackers use to hack your systems). These flaws aren’t always discovered by the vendors making the products. In fact, after a product is released they are usually discovered by outsiders who either accidentally or purposely find the vulnerabilities. Keeping with our theme of “lingo” they’re often described as “white hats”, “black hats”, and “agnostic transgender grey hats”.
You can think of disclosure as a big-ass product recall where the vendor tells you “mistakes were made” and you need to fix your car with an updated part (except they don’t recall the product, you can only get the part if you have the right support contract and enough bandwidth, you have to pay all the costs of the mechanic (unless you do it yourself), you bear all responsibility for fixing your car the right way, if you don’t fix it or fix it wrong you’re responsible for any children killed, and the car manufacturer is in no way actually responsible for the car working before the fix, after the fix, or in any related dimensions where they may sell said product). It’s really all your fault you know.
Conceptually “disclosure” is the process of releasing information about the flaw. The theory is consumers of the product have a right to know there’s a security problem, and with the right level of details can protect themselves. With “full disclosure” all information is released, sometimes before there’s a patch, sometimes after; sometimes the discoverer works with the vendor (not always), but always with intense technical detail. “Responsible disclosure” means the researcher has notified the vendor, provided them with details so they can build a fix, and doesn’t release any information to anyone until a patch is released or they find someone exploiting the flaw in the wild. Of course to some vendors use the concept of responsible disclosure as a tool to “manage” researchers looking at their products. “Graphic disclosure” refers to either full disclosure with extreme prejudice, or online dating (now with photos!).
There’s a lot of confusion, even within the industry, as to what we really mean by disclosure and it it’s good or bad to make this information public. Unlike many other industries we seem to feel it’s wrong for a vendor to fix a flaw without making it public. Some vendors even buy flaws in other vendors products; just look at the controversy around yesterday’s announcement from TippingPoint. There was a great panel with all sides represented at the recent Black Hat conference.
So what are the dirty little secrets?
- Full disclosure helps the bad guys
- It’s about ego, control, and competition
- We need the threat of full disclosure or vendors will ignore security
There. I’ve said it. Full disclosure sucks, but many vendors would screw their customers and ignore security without it.
Some of full disclosure originates with the concept that “security through obscurity” always fails. That if you keep a hole secret, the bad guys will always discover it eventually so it’s better to make it public so good guys can protect themselves. We find the roots of the security through obscurity concept in cryptography (early information security theory was dominated by cryptographers). Secret crypto techniques were bad, since they might not work; opening the mathematical equations to public scrutiny reduces the chances of flaws and improves security. As with many acts of creation it’s nearly impossible to accurately proof your own work [as my friend and unofficial editor Chris just pointed out].
But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good.
The more we disclose, the easier we make life for the bad guys. “Full disclosure” means we release all the little details. It used to be kind of tough to create an exploit from a vulnerability disclosure, but with new tools like Metasploit it takes far less skill than even a couple years ago. Exploits appear within hours or days of a vulnerability disclosure, not months. Conceptually it’s best if the good guys also know the details so we can harden our systems, make appropriate risk decisions; and so third-party security vendors can help protect us.
Whatever your position on full disclosure, and there are many good reasons for it, you need to admit that it helps the bad guys. There you go, just say it, say, “full disclosure helps script kiddies break into grandma’s computer”. It feels good, doesn’t it?
But without full disclosure many vendors would treat us like an Enron retirement plan. They’d hide vulnerabilities, avoid patching (since that costs money), and not share details with security vendors (some kids don’t play well with others). I wish it were otherwise, but we need the threat of full disclosure to help keep the vendors honest. I believe in market forces, but they only work on behalf of consumers when they’re informed. Some vendors just don’t get it, but I’ll behave and avoid naming them here.
And what about the researchers? Some are genuine do-gooders just passing on helpful information they discover as part of their job. But most vulnerabilities discovered by outsiders are used as leverage for a goal. For some it’s glory, others want access to a big product vendor, some want attention, others cash, and for security vendors it can be PR, competitive advantage, or blackmail. There is nothing wrong in wanting credit for your work, heck – I make my living getting attention – but if ego is your driver you need to constantly ask yourself if what you’re doing is for the common good or merely self enrichment. You security vendors also need some introspection – is your disclosure process a PR stunt or even blackmail to force clients to buy your service? If so you’re no better than the worst of the black hats hacking away in smoky Eastern European (or Lower East Side) bars.
I’ve worked with many responsible researchers and security vendors, but we all need to maintain constant diligence or risk crossing the line and hurting the public for self gain.
Disclosure is a simple term for an incredibly complex system of checks and balances. I won’t pretend I have all the answers; nor will I suggest, as others others deeper in the issue have, acceptable timelines and processes for disclosure. But I will suggest it’s time to bring more honesty and introspection to the debate. Only if we’re willing to strip away the subcultural lingo and admit the potential pitfalls and our motivations can we improve the process and keep grandma’s computer safe.
Even grandma needs a little online dating (now with photos!)…
Posted at Sunday 23rd February 2014 12:08 pm
(0) Comments •