Research

Nothing makes my day like getting to argue with my colleagues here at Securosis. Sadly today isn’t that day. The only thing that I love almost as much is when Mike and Rich think they are arguing with each other, but I get to point out that they are actually saying the same things, but from different angles, and therefore with different words. The fact is that both of them highlight a very important point: for security groups to be effective, they need to be much more engaged with the business. Security is in fact always reactive in the sense that they cannot do anything more than influence, until the business makes decisions about how things will be done. But there is ‘reactive’ in the sense that the business makes a choice and security deals with, it and then there’s ‘reactive’ in the sense of security teams which are completely disengaged from the business – they only know about stuff when the new app doesn’t work because the firewall rules are wrong or they get a request for a Qualys scan a couple hours before a new server must be live. But back to being engaged with the business. That doesn’t mean sitting in the C suite (though that can be nice) – it means finding out who the people & projects are in your organization which will impact your duties as a security practitioner, getting to know them, and convincing those folks to keep you in the loop. Demonstrate that you are adding value by being involved earlier – perhaps by identifying potential roadblocks and workarounds early so they can be funded, designed around, etc. Or perhaps by staying abreast of forthcoming changes to legislation/regulations and working with legal/audit to make sure your organization is ready before the changes go into effect. These are just a couple examples of ways to show that security can absolutely be proactive rather than merely reactive, and it also proves that I lied above. Today is totally that day: O frabjous day! Callooh! Callay! I get to argue with both Rich and Mike. WIN! Share:

Rich Mogull recently posted a great stream of consciousness piece about how we are at an inflection point in information security. He covers how cloud and mobility are having, and will continue to have, a huge impact on how we practice security. Rich mentions four main areas of impact: Hyper-segregation Incident response Active defense Closing the action loop The post is short but very very dense. Read it a couple times, even – there’s a lot there. I would add another consequence of these changes that has already begun and will continue to manifest over the next five to ten years. That is the operationalization of security. This is partially because security is increasingly becoming a feature rather than a product itself. Over time we will see more and more of today’s dedicated security jobs evolving into responsibilities of other roles. We already see this with patch and AV management, which are increasingly owned by the Operations rather than Security teams. Similarly, we will see development and QA picking up functions that previously belonged to security folks. Dedicated security folks will still exist, but they will fall into a much smaller set of roles, including: Advisors/subject matter experts – architects and CISOs Penetration testers Incident responders And in the case of the latter two, they will increasingly be experts brought in to handle issues beyond the capabilities of regular teams, or to satisfy requirements for third-party assessment. In many ways this will be a return to how security was in the mid-90s. Yet another example of Hoff’s Hamster Sine Wave of Pain…. h/t to Gene Kim for feedback as I wrote this post. Share:

It’s almost RSA time again. Which means one very important thing: I need to finally post the review of the very slick TPM-based Windows bootable thumb drive Jeff Jones (@securityjones) gave me at RSA 2011. I have been promising him this review since last March, and it would be just too embarrassing to not get it done before RSA 2012. So here we go. As I said above, this slick little device provides a full self-contained Windows install protected by TPM. The entire thing is encrypted. When I was still doing ops, I kept it in my car for when I was out and about without my laptop. It was great for doing quick and dirty troubleshooting using a friend’s computer or library machine without having to worry about what might be on the machine I was using. You know, those public machines can be cesspools of all sorts of badness. Unfortunately it gets less use now that I’m during pure security, but I still pull it out now and again. Pluses Completely encrypted Uses its own memory and disk instead of the host’s Great form factor Ridiculously easy to use Minuses Doesn’t play nice with some laptop video cards Not as fast as using the native hardware by a long shot Can’t boot off a Mac or via a virtual machine What would have made this better? If it completely blocked access to the underlying drives and memory of the host box. Then I would have also used it as a safe browsing environment for conferences and airports and the like. That kind of capability would also be useful for those of you who need research NSFW sites using corporate machines. Admittedly, this would be a substantial feat, especially considering the need to access USB drivers for access to the host. When I used it regularly it was great for confirming that production services were live at my company, and it also allowed me to respond to email using the web gateway. For long emails this was far more efficient then trying to use my phone. If I were buying one, I’d have them preinstall essential security tools such as gpg, 1Password or another password manager, and the appropriate strong authentication software (such as a soft token). You’d also need ssh and VPN clients to make it even more useful. And while I’m putting together a shopping list, how about Skype? That would be really nice to communicate in a pinch. Though I’m not sure if it supports audio devices. Jeff? There are a couple other good use cases. For onsite incident response I would want forensics tools. If I were doing more technical consulting/pen testing I’d want one that booted Linux so I could have tools like BackTrack at my disposal. All in all, even without those tools, it’s a nice form factor for carrying around an emergency OS. I wonder if it’d be possible to get one that dual-booted – that would be even cooler then carrying a couple. You know you have to cut ounces of extra weight when you can. And I know I can get a lot of this functionality from a regular USB thumb drive, which would greatly expand the available options and undoubtedly lower the cost. But for specialized use cases, including toting around ssh and X.509 keys, having a TPM chip and an encrypted drive is very attractive – not to mention the dedicated memory & disk. There are a couple of this type of device out there, and adhering to Securosis’ policy of not being vendor-specific, I won’t mention specific models, but if you have this kind of requirements you should check them out. Share:

Yesterday Lori MacVittie posted another thoughtful article, Cloud Computing: Architectural Limbo, where she highlights percived problems with the NIST description. I usually agree with her cloud posts, but this is a rare case where I think she is wrong. Consider, for a moment, the stark reality of a realm with no real network boundaries offered by AWS in “Building three-tier architectures with security groups”: “Unlike with traditional on-premise physical deployments, AWS’s virtualization of compute, storage, and network elements requires that you think differently about how to build network segregation into your projects. There are no distinct physical networks, no VLANs, and no DMZs.” The post goes on to describe the means in which a secure, traditional three-tiered application architecture can be deployed using AWS security groups. This architecture is a fine approximation of the traditional, data center deployed architecture based on the available abstractions offered by AWS Note the use of the term “approximation”. That’s important, because it’s indicative of one of the core issues with cloud today: the inability to replicate architecture. You might be thinking that’s okay as long as you can replicate it using available services. Actually, it is okay because it does work. AWS does provide logical and physical barriers, and while they are presented in a way that only mimics traditional networks, they do so to ease understanding through familiar concepts. Being different does not make it less secure. And I’ve lost count of the number of organizations that have successfully deployed this (admittedly basic) architecture and are running it in production environments. It works so well that we even teach it in the CSA Certificate of Cloud Security Knowledge (CCSK) classes we run. One of the great joys of running in an IaaS environment is its bare simplicity. You don’t have the crutches of a vast array of technology to rely on. Instead you have to think about your real needs, instead of adding huge amounts of complexity because that’s how we’re doing it in-house today. It’s a prime opportunity to start over and avoid repeating the sins of the past. The problem is that in order to fully deploy in the cloud you have to deploy an architecture that will be different from the one you currently maintain in the data center. What that ultimately entails is a separate and environment-specific set of processes, as well, that could quickly become operationally expensive. This is especially true when compliance enters the picture, and even more so when the regulations in question are those that focus on process (think SOX) and not just technological implementation. While it is true that in many cases, different network architectures and security requirements cause differences in cloud architectures, that doesn’t necessarily mean that the applications residing on those architectures will be fundamentally different. In my experience most operations teams have little or no knowledge of how the underlying network architectures are laid out. It’s simply irrelevant, so long as the necessary ports are open. And this is the model offered by cloud providers like AWS. As for separate and environment-specific sets of processes, this is just a red herring. Network and especially security teams already have to do this, especially in larger organizations. You could just as well make this argument about every application deployment, regardless of locale. This is just part of life, and any good IT shop should be familiar it. Share:

There has been plenty of discussion of what HP’s recent acquisition of Fortify means in terms of commoditization and consolidation in the market. The reality is that most acquisitions by large vendors are about covering perceived holes in their product line. In other words this is really just the market acknowledging the legitimacy of the product or feature set. Don’t get me wrong – legitimization is very important, but it doesn’t necessarily mean either consolidation or commoditization, though they both indicate some level of legitimization. Commoditization is actually at odds with consolidation. Like legitimization, they are both important aspects of the product/market maturity curve. Consolidation is when the number of vendors in a market radically decreases due to acquisitions by larger vendors (HP, IBM, McAfee, Symantec – you get the idea) or straight failures causing companies to shut down. Consolidation – especially the acquisition type – indicates that the product space is beginning to be legitimized in the eyes of customers. At the other end of the legitimization/maturity curve we have commoditization. This is where the market has completely legitimized the product space, and in fact there is little to no innovation going on there. Essentially all the products have become morally equivalent, and as far as customers are concerned there is little or no compelling technical reason to choose one vendor over another. At that point it comes down to cost: which vendor will provide the product at the lowest capital and operational costs? De-consolidation is also correlated with commoditization. One key indicator of commoditization is an increase in the number of vendors. A great example of this is desktops, laptops, and servers. They are pretty much all the same and it’s really a question of which nameplate is on the front. In the security space, you can see this clearly with firewalls/routers for small offices & homes (“SOHO”), and we are starting to see it with AV as well. As for HP buying Fortify, it’s neither consolidation nor commoditization. The market hasn’t shifted in either direction enough for those. It is, however, legitimization of code auditing tools as a product category.   Share:

Recently Michael Zalewski posted a rant about the state of security engineering in Security engineering: broken promises. I posted my initial response to this on Twitter: “Great explanation of the issue, zero thoughts on solutions. Bored now.” I still stand behind that response. As a manager, problems without potential solutions are useless to me. The solutions don’t need to be deep technical solutions – sometimes the solution is to monitor or audit. Sometimes the solution is to do nothing, accept the risk, and make a note of it in case it comes up in conversation or an audit. But as I’ve mulled over this post over the last two weeks, there is more going on here. There seems to be a prevalent attitude among security practitioners in general, and researchers in particular, that if they can break something it’s completely useless. There’s an old Yiddish saying that loosely translates to: “To a thief there is no lock.” We’re never going to have perfect security, so picking on something for being imperfect is just disingenuous and grandstanding. We need to be asking ourselves a pragmatic question: Does this technology or process make things better? Just about any researcher will tell you that Microsoft’s SDL has made their lives much harder, and they have to work a lot more to break stuff. Is it perfect? No, of course not! But is it a lot better then it used to be for all involved (except the researchers Microsoft created the SDL to impede)? You betcha. Are CWE and CVSS perfect? No! Were they intended to be? No! But again, they’re a lot better than what we had before. Can we improve them? Yes, CVSS continues to go through revisions and will get better. As will the Risk Management frameworks. So really, while bitching is fun and all, if you’re not offering improvements, you’re just making things worse. Share:

One of our readers recently emailed me with a major dilemma. They need to keep their website PCI compliant in order to keep using their payment gateway to process credit card transactions. Their PCI scanner is telling them they have vulnerabilities, while their hosting provider tells them they are fine. Meanwhile our reader is caught in the middle, paying fines. I don’t dare to use my business e-mail address, because it would disclose my business name. I have been battling with my website host and security vendor concerning the Non-PCI Compliance of my website. It is actually my host’s IP address that is being scanned and for several months it has had ONE Critical and at least SIX High Risk scan results. This has caused my Payment Gateway provider to start penalizing me $XXXX per month for Non-PCI compliance. I wonder how long they will even keep me. When I contact my host, they say their system is in compliance. My security vendor is saying they are not. They are each saying I have to resolve the problem, although I am in the middle. Is there not a review board that can resolve this issue? I can’t do anything with my host’s system, and don’t know enough gibberish to even interpret the scan results. I have just been sending them to my host for the last several months. There is no way that this could be the first or last time this has happened, or will happen, to someone in this situation. This sort of thing is bound to come up in compliance situations where the customer doesn’t own the underlying infrastructure, whether it’s a traditional hosted offering, and ASP, or the cloud. How do you recommend the reader – or anyone else stuck in this situation – should proceed? How would you manage being stuck between two rocks and a hard place? Share:

Today Verizon released their Supplement to the 2009 Data Breach Investigations Report. As with previous reports, it is extremely well written, densely loaded with data, and an absolute must read. The bulk of the report gives significantly more information on the breakdown of attacks, by both how often attacks occurred, and how many records were lost as a result of each attack. While the above is fascinating, where things got most interesting was in the appendix, which was all about comparing the Verizon data set from 2004 through 2008 to the DataLossDB archives from 2000-2009. One of the big outstanding questions from past Verizon reports was how biased is the Verizon dataset, and thus how well does it reflect the world at large? While there was some overlap with the DataLossDB, their dataset is significantly larger (2,300+ events). Verizon discovered a fairly high level of correlation between the two data sets. (Page 25, Table 4). This is huge, because it allows us to start extrapolating about the world at large and what attacks might look like to other organizations. The great thing about having so much data is that we can now start to prioritize how we implement controls and processes. Case in point: Table 5 on page 26. We once again see that the vast vast majority (over 70%!) of incidents are from outsiders. This tells us that’s where protection should be focused first. If you go back to the body of the supplement and start looking at the details, you can start to re-evaluate your current program and re-prioritize appropriately. Share:

My Friday post generated some great discussion in the comments. I encourage you to go back and read through them. Rocky in particular wrote an extended comment that should be a blog post in itself which reveals that he and I are, in fact, in violent agreement on the issues. Case in point, his first paragraph: I think we’re on the same page. As an industry we need to communicate more clearly. It wasn’t my intent to fault any information professionals as much as I’m hoping that we all will push a bit harder for the right conversations in the future. We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue. We’re yelling in the wrong language. We just need to put that effort into learning their language and communicating more effectively. How is it that we can read HEX in real time but can’t converse with a MBA at any time? Read the last sentence again. It is that important. This is something I’ve been fighting for for a long time. It’s not about bits and bytes and until we get that through our heads, the rest just doesn’t matter because no one in command will listen to us. Rocky closed out his comment with this though: What would IT security look like if we spent as much time on those thoughts as we do on compliance tools, dashboards and monitoring? I think it’d be much more business centric and hopefully significantly more respected in the C-suite. What do you think? Share:

Rocky DeStefano had a great post today on FudSec, Liberate Yourself: Change The Game To Suit Your Needs, which you should read if you haven’t already. It nicely highlights many of the issues going on in the industry today. However, I just can’t agree with all of his assertions. In particular, he had two statements that really bothered me. Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally secure – or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements – irrelevant because they are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary. In a perfect, security and risk oriented world, I would agree with this 100%. The problem is, that from the business perspective, what they have in place is usually sufficient to do what they need to do safely. I’m a big fan of using risk, because it’s the language that the business uses, but this isn’t really a compliance versus security vs risk issue. What needs to be communicated more effectively is what compliance to the letter of the law does and doesn’t get you. Where we have failed as practitioners is in making this distinction and allowing vendor and marketing BS to convince business folks that because they are compliant they are of course secure. I can’t count the number of times I’ve had folks tell me that they thought being compliant with whatever regulation meant they were secure. Why? Because that’s the bill of sale they were sold. And until we can change this basic perception the rest seems irrelevant. Don’t blame the security practitioners; most of the ones I know clearly express the difference between compliance and security, but it often falls on deaf ears. But what really got my goat was this next section: As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim? I don’t know who Rocky has been talking to, but I don’t know a single security practitioner who thinks that compliance was the way to go. What I’ve seen are two general schools of thought. One is to rant and rave that everyone is doing it wrong and that compliance doesn’t equal security, but then engages in the compliance efforts because they have no choice. The other school is to be pragmatic and to accept that compliance is here to stay, and do our best within the existing framework. It’s not like we as an industry ‘let’ compliance happen. Even the small group of folks who have managed to communicate well with the business, be proactive, and build a mature program still have to deal with compliance. As for Rocky’s “buildng codes” and “point in time” snapshots, for a huge segment of the business world, this is a massive step up from what they had before. But to answer Rocky’s question, the failure here is that we told the business, repeatedly, that if they installed this one silver bullet (firewalls, AV, IDS, and let’s not forget PKI) they’d be secure. And you know what? They believed us, every single time, they shelled out the bucks and we came back for more, like Bullwinkle the Moose “This time for sure!” We told them the sky was going to fall and it didn’t. We FUDed our way around the business, we were arrogant and we were wrong. This wasn’t about selling our souls to compliance. It was about getting our asses handed to us because we were too busy promoting “the right way to do things” and telling the business no rather then trying to enable them to achieve their goals. Want an example? Show me any reasonable evidence that changing all your users’ passwords every 90 days reduces your risk of being exploited. No wonder they don’t always listen to us. Share: