Research

Few terms strike as much dread in the hearts of security professionals as key management. Those two simple words evoke painful memories of massive PKI failures, with millions spent to send encrypted email to the person in the adjacent cube. Or perhaps it recalls the head-splitting migraine you got when assigned to reconcile incompatible proprietary implementations of a single encryption standard. Or memories of half-baked product implementations that worked fine on in isolation on a single system, but were effectively impossible to manage at scale. And by scale, I mean “more than one”. Over the years key management has mostly been a difficult and complex process. This has been aggravated by the recent resurgence in encryption – driven by regulatory compliance, cloud computing, mobility, and fundamental security needs. Fortunately, encryption today is not the encryption of yesteryear. New techniques and tools remove much of the historical pain of key management – while also supporting new and innovative uses. We also see a change in how organizations approach key management – a move toward practical and lightweight solutions. In this series we will explore the latest approaches for pragmatic key management. We will start with the fundamentals of crypto systems rather than encryption algorithms, what they mean for enterprise deployment, and how to select a strategy that suits your particular project requirements. The historic pain of key management Technically there is no reason key management needs to be as hard as it has been. A key is little more than a blob of text to store and exchange as needed. The problem is that everyone implements their own methods of storing, using, and exchanging keys. No two systems worked exactly alike, and many encryption implementations and products didn’t include the features needed to use encryption in the real world – and still don’t. Many products with encryption features supported only their own proprietary key management – which often failed to meet enterprise requirements in areas such as rotation, backup, separation of duties, and reporting. Encryption is featured in many different types of products but developers who plug an encryption library into an existing tool have (historically) rarely had enough experience in key management to produce refined, easy to use, and effective systems. On the other hand, some security professionals remember early failed PKI deployments that costs millions and provided little value. This was at the opposite end of the spectrum – key management deployed for its own sake, without thought given to how the keys and certificates would be used. Why key management isn’t as hard as you think it is As with most technologies, key management has advanced significantly since those days. Current tools and strategies offer a spectrum of possibilities, all far better standardized and with much more robust management capabilities. We no longer have to deploy key management with an all-or-nothing approach, either relying completely on local management or on an enterprise-wide deployment. Increased standardization (powered in large part by KMIP, the Key Management Interoperability Protocol) and improved, enterprise-class key management tools make it much easier to fit deployments to requirements. Products that implement encryption now tend to include better management features, with increased support for external key management systems when those features are insufficient. We now have smoother migration paths which support a much broader range of scenarios. I am not saying life is now perfect. There are plenty of products that still rely on poorly implemented key management and don’t support KMIP or other ways of integrating with external key managers, but fortunately they are slowly dying off or being fixed due to constant customer pressure. Additionally, dedicated key managers often support a range of non-standards-based integration options for those laggards. It isn’t always great, but it is much easier to mange keys now than even a few years ago. The new business drivers for encryption and key management These advances are driven by increasing customer use of, and demand for, encryption. We can trace this back to 3 primary drivers: Expanding and sustained regulatory demand for encryption. Encryption has always been hinted at by a variety of regulations, but it is now mandated in industry compliance standards (most notably the Payment Card Industry Data Security Standard – PCI-DSS) and certain government regulations. Even when it isn’t mandated, most breach disclosure laws reduce or eliminate the need to publicly report loss of client information if the lost data was encrypted. Increasing use of cloud computing and external service providers. Customers of cloud and other hosting providers want to protect their data when they give up physical control of it. While the provider often has better security than the customer, this doesn’t reduce our visceral response to someone else handling our sensitive information. The increase in public data exposures. While we can’t precisely quantify the growth of actual data loss, it is certainly far more public than it has ever been before. Executives who previously ignored data security concerns are now asking security managers how to stay out of the headlines. More enforcement of more regulations, increasing use of outsiders to manage our data, and increasing awareness of data loss problems, are all combining to produce the greatest growth the encryption market has seen in a long time. Key management isn’t just about encryption (but that is our focus today) Before we delve into how to manage keys, it is important to remember that cryptographic keys are used for more than just encryption, and that there are many different kinds of encryption. Our focus in this series is on data encryption – not digital signing, authentication, identity verification, or other crypto operations. We will not spend much time on digital certificates, certificate authorities, or other signature-based operations. Instead we will focus on data encryption, which is only one area of cryptography. Much of what we see is as much a philosophical change as improvement in particular tools or techniques. I have long been bothered people’s tendency to either indulge in encryption idealism at one end, and or dive

Rich here. One of the more fascinating – and unexpected – aspects of migrating from martial arts to triathlon as my primary sport has been importance role of metrics, and how they have changed my views on security. Both sports are pretty darn geeky. On the martial arts side we have intense history, technique, and strategy. Positional errors of a fraction of an inch can mean the difference between success, failure, and injury. But overall there is less emphasis on hard metrics. We use them for conditioning but lack much of the instrumentation needed to collect the kinds of metrics that can make the difference between victory and defeat in competition. For example, very few martial artists could gather hard statistics on how an opponent reacts under specific circumstances, never mind translating that to a specific strategy. Nor do we measure things like speed and power in specific physical configurations. Some martial artists track some fraction of this at a macro level, but generally not with statistical depth. I remember that when training for nationals I knew I would be up against one particular opponent and I studied his strengths, weaknesses, and reactions in certain situations, but I certainly didn’t calculate anything. Besides, some 16 year old kid kicked my ass in the first round and I never went up against the person I planned for (major nutritional failure on my part). Oops. A lot of strategy. Sometimes metrics, but not often and not solid. And a lot of reliance on instinct and core training. Sounds a lot like security. Triathlon is on the opposite end of the spectrum – as are most endurance sports. There is definitely strategy, but even that is defined mostly by raw numbers. I have been tracking my athletic performance metrics fairly intensely since I moved mostly to endurance sports (due to the kids). This started around 10 years ago, although only over the last 3 years have I really focused on it. Additionally, since getting sick last summer I have also started tracking all sorts of other metrics – mostly my daily movements (Jawbone Up, which isn’t available right now), and sleep (Zeo). For the past year I have kept most of this in TrainingPeaks. I’m learning more about myself than I thought possible. I know what paces I can sustain, and what distances, to within a handful of seconds. I know how those are affected by different weather conditions. I know exactly how what I eat affects how I perform different kinds of workouts. I know how food, exercise, and alcohol affect my sleep. I have learned things like how to dial in my diet (no carb no good, but mostly natural with a small amount of processed carbs hits the sweet spot). I know how many days I can go on reduced sleep before I am more likely to get sick. I even figured out just about exactly what will cause one of the stomach incidents that freaked me out so badly last year. I pretty much track myself 24/7. The Jawbone counts how much I move during the day. The Zeo how well I sleep. My Garmin 910XT how well I swim, bike, and run. A Withings scale for weight and body fat. And TrainingPeaks for mood, illness, injury, training stress (mathematically calculated from my workouts), and whatever else I want to put in there. (I have toyed with diet, but don’t really track calories yet). I measure, track over time, and then correlate to make training and lifestyle decisions. These are not theoretical – I use those metrics to change how I live, and then I track my outcomes. I know, for example, that I can optimize my training in the amount of time I have for triathlon, but my single sport performance drops to predictable degrees. All this for someone back-of-pack and over 40. The pros? The levels to which they can tune their lives and training are insane. And it all directly affects performance and their ability to win. But, as with everything, the numbers don’t tell the full story. They can’t precisely predict who will win on race day. Maybe the leader will get caught behind a crash. Maybe they’ll miss just enough sleep, or hit a crosswind at the wrong time, or just have an off day. Maybe someone else will dig deep and blow past everything the numbers predict. But without those numbers, tracked and acted on, for years on end, no pro would ever have a chance of being in the race. Security today is a lot more like martial arts than triathlon, but I’m starting to think the ratio is skewed in the wrong direction. We can track a lot more than we do, and base far more decisions on data than on instinct. Yes, we are battling an opponent, but our race lasts years – not three five-minute rounds. And unlike professional martial artists, we don’t even know our ideal fighting weight, never mind our conditioning level. Believe it or not, I wasn’t always a metrics wonk. I used to think skill and instinct mattered more than anything else. The older I get, the more I realize how very wrong that is. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike’s monthly Dark Reading blog: Time to deploy the FUD weapon? Rich quoted by the Macalope: The Macalope Daily: Protesting too much (Subscription required). Favorite Securosis Posts Adrian Lane: Evolving Endpoint Malware Detection: Control Lost. New threats and redefining what ‘endpoint’ actually means are a couple good reasons to follow this series. Mike Rothman: Understanding and Selecting Data Masking: Introduction. Masking is a truly under-appreciated function. Until your production data shows up in an Internet-accessible cloud instance, that is. Adrian’s series should shed some light on this topic. Rich: Continuous Learning. I’m not sure my quote fit here, but I’m sure a fan of people diversifying their knowledge. Other Securosis Posts Our posting volume is down a bit due to

One of the things I truly love about writing for Securosis and TidBITS is that I am rarely put in a position where I need to be first to write about something. As a writer, and occasionally a journalist, I consider time the ultimate luxury. Unfortunately, few journalists have this liberty, and even fewer appreciate it. Yesterday was a perfect and tragic expression of the state of modern media, where writers are forced to report – not only as quickly as possible, but often without any facts or sources. It all started with a computing.co.uk article quoting the CTO of Kaspersky claiming they were “working with Apple” to analyze OS X (at Apple’s request). To anyone with any knowledge of Apple this was obviously less likely than me giving birth to a flying monkey. There were three possible options here: Kaspersky lied. The reporter didn’t hear correctly. The reporter lied. Kaspersky was telling the truth, in violation of whatever NDA they signed with Apple. Here’s where it got interesting. After that initial article, all sorts of other outlets started reporting the news – from CNet and TUAW, to The Verge and Ars Technica. All quoting the same source – the computing.co.uk article. Within a few hours Kaspersky’s CTO walked back the claim and said he was quoted out of context. computing.co.uk claimed they asked the question multiple times for clarity and the claim was clear and explicit. Then all the other articles issued updates and corrections. This isn’t about Apple, and this isn’t about Kaspersky. It isn’t even a flagellation of the media – they are effectively forced to ‘report’ stories without sources or confirmation, due to their market conditions. But as readers (and for some of us, writers), it’s important to understand that environment – especially where security is concerned. Few media outlets rely on multiple sources and traditional journalistic standards anymore. Many issue ‘definitive’ articles based on tweets, blog posts, or something they heard while sitting quietly on the crapper (if they work for News Corp). The first reports are usually wrong. The second reports are usually copies of the first report. The third round of articles is where the truth might start creeping in. Every time I witness one of these throwdowns or walkbacks, I feel incredibly fortunate that my livelihood isn’t dependent on capturing page views. Share:

Rich here. It amazes me how something completely mundane can be utterly fascinating the first time you experience it. This morning I woke up about 5:45 as I heard my younger daughter waking up herself. If history held, she had been up for a little while and was ready to get out of her crib. Now!!! Nothing new there, and I started the painful process of getting out of bed (I d hammered my bad shoulder a little too much during my swim workout yesterday, leading to a painful night). Here’s the cool bit. Our older daughter (who is only 3) came barging in to tell us her little sister wanted out of the crib. This is the same 3-year-old who was still calling for us to get her out of her toddler bed a mere week or so ago. Oh, she could easily extricate herself, but the habit of yelling for us to get her was deeply ingrained. She’d sit there yelling for one of us while clutching her stuffed animals and blanket, only to hand them over so she could climb out. So I got out of bed, went down the hall to the little one’s open door, and carried her downstairs. Then I noticed big sister’s stuff already there on her spot on the couch. “Have you been up for a while?” “Yes.” “What were you doing?” “I was giving the cat some treats.” This is, relatively speaking, nothing. We all get out of bed ourselves in the morning and start our days. But it was the first time one of our kids got out of bed, took her stuff downstairs, and played with the cat without waking anyone else up. And 20 years from now the odds are I won’t remember it. But damn – for this one moment I was more impressed and proud of this tiny little thing we all do, and all kids do, than any “big” accomplishments (whatever those are). The best part? She’d even put the cat treats away in the drawer. I think I like this parenting thing. Despite the lack of sleep, large amounts of vomit I’m occasionally covered with, and all the interesting places I’ve now gotten to clean shit out or off of. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike quoted on cloud security on ServicesAngle. Rich quoted on 10 years of Microsoft’s Trustworthy Computing Initiative. Adrian quoted in SecurityWeek on WAF & SDLC. Adrian quoted in Tech Republic on User Behavior Monitoring.. Favorite Securosis Posts Adrian Lane: FireStarter: Policy Wonks and Pests. Yes, my own post. But as Rich said, this is a huge beef we have and we see it all too often with cloud security. Rich: Okay, we were a little light on blogging this week. I promise to make up for it next week! Other Securosis Posts Incite 2/9/2012: Swimming with Sharks. Favorite Outside Posts Mike Rothman: How to make money online. This post actually isn’t about making money. It’s about being successful in today’s online environment. And Godin is a philosopher king, so ignore his guidance at your own risk. Adrian Lane: Citadel Trojan Outgrowing Its Zeus Origins. Interesting post on the RSA blog about the Citadel Trojan – see how attackers improve their code. Rich: Joss Whedon interview at GQ. I’m sorry, but I’m an intense geek and the fact that some studio tossed Joss $220M (far more than most security companies are worth) just tickles me pink. Research Reports and Presentations Watching the Watchers: Guarding the Keys to the Kingdom. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Top News and Posts Random network security tip if you are on TV. Amusing. Getting started with OpenStack in your lab. Now where were you when I was building the CCSK class labs? Sigh. Apple hardens Safari and OS X with latest update. FBI warns travelers about hotel Internet connections. Gee, China anyone? Blog Comment of the Week This would have required us to, uh, blog… so no comment this week. Share:

Rich here. I’m writing thi from an airport, so I will eschew my normal ‘personal’ intro and spend a little time on our favorite security show: Airport Screening Follies. (But before I do that, go buy Motherless Children by Dennis Fisher. Dennis is an actual writer, and despite him screwing up an EMT reference it’s a great book (so far… nearly halfway through)). It’s easy to knock the TSA. But like kicking a puppy, it’s also far from satisfying. And while it’s also easy to criticize specific screening techniques, it might be more useful to understand them. Because if we really want our airport traveling experience to change, we need to attack the economics and stop wasting our time focusing on the value of particular security controls, or the failings of a small percentage of the workforce. If we look at the TSA, there are really three levels of people involved (not counting the public): Policymakers (politicians) TSA executives (and high-level appointees) TSA staff Let’s take a moment to look at the dynamics at each level. Politicians only care about being reelected, and don’t want any responsbility for their actions. To them the risk of changing the TSA is that on the off chance something bad, happens they will be excoriated (worst case: not re-elected). The reward for actually changing TSA practices is low, while the reward for posturing is high. In other words: if a politician implements a reduction in security and something bad happens they are likely to be held responsible even if it’s a coincidence; but proposing bills that don’t pass, loudly demanding tigher security (even if their demands are meaningless), and spending complaining to the press, all help them get reelected. So they all talk a lot without doing anything useful. TSA execs – the high-level decision-makers – face the same risks as politicians. Drop a single pointless security ‘control’, and when the next event happens they will be stoned by politicians, press, and the public. There is no cost to them for implementing more security theater, but there is a high risk from removing anything. It’s not an evil mindset, and not one they are necessarily conscious of, but the sad truth is that it is at least as important for them to look like they are doing anything to address every potential visible risk, as to actually stop an attack or improve transportation. TSA staff mostly just want to keep their jobs. One important way to do that is to buy into the security theater. They also want to feel good about their work, so like an AV vendor hyping Mac malware, they believe that even low-value security is important – it’s what they do, day to day. I don’t mean this in an insulting way. There is actually a lot of value in screening, although certain TSA technologies and practices are basically pointless. When you are in the trenches, it is often hard to divest yourself emotionally and to understand the differences objectively. I’m fairly certain that many of our fine readers enforce plenty of IT security theater (especially when it comes to passwords), so you all know what I mean. As a guy who used to hand-search thousands of concert and football attendees, I get it. What about the flying public? The only thing we can control is the political environment, and if we aren’t going to hold our elected officials responsible for their economic foibles we certainly aren’t going to vote based on who will change the TSA. So our politicians really have nothing vested in reducing security theater. We have executives and appointees who see only a downside to reducing it, because public complaints don’t really affect them. And they are motivated to double down when challenged so they seem ‘decisive’ and knowledgeable. Last we have the staffers who just want to keep their jobs and go home without feeling like asses. It’s all risk/reward, and the odds certainly do not favor the flying public. Until the political climate for security theater becomes untenable nothing will change. And that won’t happen as long as we have 24-hour news channels and talk radio. Oh – and this all applies to CISPA, and whatever else is pissing you off today. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s paper on User Activity Monitoring. Favorite Securosis Posts Adrian Lane: Vulnerability Management Evolution: Value-Add Technologies. This is the type of graphics we need more of. Mike Rothman: Understanding and Selecting DSP: Use Cases. In case some of the theory behind DSP wasn’t clear, these use cases should clarify things. This was a great series. Rich: Mike’s Privileged User Management paper – this is heating up. Other Securosis Posts Incite 4/25/2012: Drafty Draft. Watching the Watchers: Integration. Vulnerability Management Evolution: Core Technologies. Vulnerability Management Evolution: Value-Add Technologies. Vulnerability Management Evolution: Enterprise Features and Integration. Favorite Outside Posts Mike Rothman: Motherless Children (buy it now!). Our friend Dennis Fisher published a novel. You can buy it on the Kindle and within a week or so you’ll be able to buy a paperback version. I’m getting my copy this weekend. You should too. Mike Rothman: The Mystery of the Flying Laptop. We all get security theater. Nice to see a mass market pub lampoon the idiocy of flying with electronics in the US. Rich: Bill Brenner on the TSA – tying into my intro. Research Reports and Presentations Watching the Watchers: Guarding the Keys to the Kingdom. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Top News and Posts Mozilla Weighing Opt-In Requirement for Web Plugins. This is already available, if you use the Add-on tool to keep all this stuff turned off. US and China conduct cyber-war games. Hotmail Password Reset Bug Exploited in Wild. Critical 0day in Oracle. Backdoor

Database Security Platforms are incredibly versatile – offering benefits for security, compliance, and even operations. The following are some classic use cases and ways we often see them used: Monitoring and assessment for regulatory compliance Traditionally the biggest driver for purchasing a DAM/DSP product was to assist with compliance, with Sarbanes-Oxley (SOX) almost single-handedly driving the early market. The features were mostly used in for compliance in a few particular ways: To assess in-scope databases for known security issues and policy compliance. Some regulations require periodic database assessment for security issues, policy (configuration) compliance, or both. To assess databases for entitlement issues related to regulatory compliance. While all vulnerability tools can assess database platforms to some degree, no non-database-specific tools can perform credentialed scanning and assessment of user entitlements. This is now often required by certain regulations to ensure users cannot operate outside their designated scope, and to catch issues like users assigned multiple roles which create a conflict of interest. This can be evaluated manually, but it is far more efficient to use a tool if one is available. To monitor database administrators. This is often the single largest reason to use a DSP product in a compliance project. For comprehensive compliance reports spanning multiple databases and applications. Policy-level reports demonstrate that controls are in place, while other reports provide the audit trail necessary to validate the control. Most tools include such reports for a variety of major regulations, with tailored formats by industry. Web application security Almost all web applications are backed by databases, so SQL injection is one of the top three ways to remotely attack them. Web Applications Firewalls can block some SQL injection, but a key limitation is that they don’t necessarily understand the database they are protecting, and so are prone false positives and negatives. DSPs provide a similar capability – at least for database attacks – but with detailed knowledge of both the database type and how the application uses it. For example, if a web application typically queries a database for credit card numbers, the DSP tool can generate an alert if the application requests more card numbers than a defined threshold (often 1). A DSP tool with content analysis can do the same thing without the operator having to identify the fields containing credit card numbers. Instead you can set a generic “credit card” policy that alerts any time a credit card is returned in a query to the web application server, as nearly no front-end applications ask for full card numbers anymore – they are typically left to transaction systems instead. We have only scratched the surface of the potential security benefits for web apps. For example, query whitelisting can alert any time new queries or patterns appear. It is increasingly common for attackers to inject or alter stored procedures in order to take control of databases, and stored procedure monitoring picks up attacks that a WAF might miss. Some tools on the market even communicate violations back to a WAF, either for alerting or to terminate suspicious sessions and even block the offending IP address. Change management Critical databases go down more often due to poor change management than due to attacks. Unlike application code changes, administrators commonly jump right into production databases and directly manipulate data in ways that can easily cause outages. Adding closed-loop change management supported by DSP reduces the likelihood of a bad change, and provides much deeper accountability – even if shared credentials are used. Every administrator action in the database can be tracked and correlated back to a specific change ticket, with monitoring showing the full log of every SQL command – and often return values as well. Legacy system and service account support Many older databases have terrible logging and auditing features that can crush database performance, when they are even available. Such older databases are also likely to include poorly secured service accounts (although we concede that stored plain-text credentials for application accounts are still all too common in general). DSP can generate an audit trail where the database itself does not offer one, and DSP tools tend to support older databases – even those no longer supported by the database vendor. Even modern databases with auditing tend to impose a greater performance impact than DSPs. They can also audit service accounts – generic accounts used by applications to speed up performance – and even alert on unusual activity. This can be especially useful with even a simple rule – such as alerting on any access attempt using service account credentials from anywhere other than the application server’s IP address. And with that, we have wrapped up our series on Database Security Platforms. Share:

I still consider myself a relative newcomer to the Mac community. Despite being the Security Editor at TidBITS and an occasional contributor to Macworld (print and online), and having spoken at Macworld Expo a couple times, I only really switched to Macs back in 2005. To keep this in perspective, TidBITS has been published electronically since 1990. Coming from the security world I had certain expectations of the Mac community. I thought they were naive and smug about security, and living in their own isolated world. That couldn’t have been further from the truth. Over the past 7 years, especially the past 5+ since I left Gartner and could start writing for Mac publications, I have learned that Mac users care about security every bit as much as Windows users. I haven’t met a single Mac pundit who ever dismissed Mac security issues or the potential for malware, or who thought their Mac ‘immune’. From Gruber, to Macworld, to TidBITS, and even The Macalope (a close personal friend when he isn’t busy shedding on my couch, drinking my beer out of the cat’s water bowl, or ripping up my drapes with his antlers) not one person I’ve met or worked with has expressed any of the “security smugness” attributed to them by articles like the following: Are MACS Safer then PCs Flashback Mac Trojan Shakes Apple Rep of Invulnerability Widespread Virus Proves Macs Are No Longer Safe From Hackers Expert: Mac users more vulnerable than Windows users And countless tweets and other articles. Worse yet, the vast majority of Mac users worry about security. When I first started getting out into the Mac community people didn’t say, “Well, we don’t need to worry about security.” They asked, “What do I need to worry about?” Typical Mac users from all walks of life knew they weren’t being exploited on a daily basis, but were generally worried that there might be something they were missing. Especially relatively recent converts who had spent years running Windows XP. This is anecdotal, and I don’t have survey numbers to back it up, but I’ve been probably the most prominent writer on Mac security for the past 5 years, and talk to a ton of people in person and over email. Nearly universally Mac users are and have been, concerned about security and malware. So where does this myth come from? I think it’s 3 sources: An overly vocal minority who fill up the comments on blog posts and news articles. Yep – a big chunk of them are trolls and asshats. There are zealots like this for every technology, cause, and meme on the face of the planet. They don’t represent our community, no matter how many Apple stickers are on the backs of their cars and work-mandated Windows laptops. One single advertisement where Apple made fun of the sick PC. One. Single. Singular. Unique. Apple only ever made that joke once, and it was in a single “I’m a Mac” spot. And it was 100% accurate at the time – there was no significant Mac malware then. But since then we have seen countless claims that Apple is ‘misleading’ users. Did Apple downplay security issues? Certainly… but nearly exclusively during a period when people weren’t being exploited. I’m not going to apologize for Apple’s security failings (especially their patching issues, which lad to the current Flashback issue), but those are very different than actively misleading users. Okay – one of the Securosis staff believe there may have been some print references from pre-2005, but we are still talking small numbers and nothing current. Antivirus vendors. Here I need to tread cautiously here because I have many friends at these companies who do very good work. Top-tier researchers that are vital to our community. But they have a contingent, just like the Mac4EVER zealots, who think people are stupid or naive if they don’t use AV. These are the same people who want Apple to remove iOS security so they can run their AV products on your phones. Who took out full page advertisements against Microsoft when MS was going to lock down parts of the Windows kernel (breaking their products) for better security. Who issue report after report designed only to frighten you into using their products. Who have been claiming that this year really will be the the year of mobile malware (eventually they’ll be right, if we wait long enough). Here’s the thing. The very worst quotes and articles attacking smug Mac users usually use a line similar to the following: Mac users think they are immune because they don’t install antivirus. Which is a logical fallacy of the highest order. These people promote AV as providing the same immunity they say Mac zealots claim for ‘unprotected’ Macs. They gloss over the limited effectiveness of AV products. How even the AV vendors didn’t have signatures for Flashfake until weeks after the infections started. How Windows users are constantly infected despite using AV, to the point where most enterprise security pros I work with see desktop antivirus as more a compliance tool and high-level filter than a reliable security control. I’m not anti-AV. It plays a role, and some of the newer products (especially on the enterprise side) which rely less on signatures are showing better effectiveness (if you aren’t individually targeted). Plus most of those products include other security features, ranging from encryption to data loss prevention, that can be useful. I also recommend AV extensively for email and network filtering. Even on Macs, sometimes you need AV. I am far more concerned about the false sense of immunity claimed by antivirus vendors than smug Mac users. Because the security-smug Mac user community is a myth, but the claims of the pro-AV community (mostly AV vendors) are very real, and backed by large marketing budgets. Update: Andrew Jaquith nailed this issue a while ago over at SecurityWeek: Note to readers: whenever you see or hear an author voicing contempt for customers by calling them arrogant, smug, complacent, oblivious, shiny-shiny obsessed members of a cabal, “living in a false paradise,” or

Over at TidBITS today I published a non-security-geek oriented article on how to tell if your cloud provider can read your data. Since many of you are security geeks, here’s the short version (mostly cut and paste) and some more technical info. The short version? If you don’t encrypt it and manage keys yourself, of course someone on their side can read it (99+% of the time). There are three easy indicators that your cloud provider (especially SaaS providers) can read your data: If you can see your data in a web browser after entering only your account password, the odds are extremely high that your provider can read it as well. The only way you could see your data in a web browser and still have it be hidden from your provider would require complex (fragile) JavaScript code, or a Flash/Java/ActiveX control to decrypt and display the data locally. If the service offers both web access and a desktop application, and you can access your data in both with the same account password, the odds are high that your provider can read your data. The common access indicates that your account password is probably being used to protect your data (usually your password is used to unlock your encryption key). While your provider could architect things so the same password is used in different ways to both encrypt data and allow web access, that doesn’t really happen. If you can access the cloud service from a new device or application by simply providing your user name and password, your provider can probably read your data. This is how I knew Dropbox could read my files long before that story hit the press. Once I saw that I could log in and see my files, or view them on my iPad without using an encryption key other than my account password, I knew that my data was encrypted with a key Dropbox that manages. The same goes for the enterprise-focused file sharing service Box (even though it’s hard to tell from reading their site). Of course, since Dropbox stores just files, you can apply your own encryption before Dropbox ever sees your data, as I explained last year. And iCloud? With iCloud I have a single user name and password. Apple offers a rich and well-designed web interface where I can manage individual email messages, calendar entries, and more. I can register new devices and computers with the same user name and password I use on the web site. So it has always been clear that Apple could read my content, just as Ars Technica reported recently (with quotes from me). That doesn’t mean that Dropbox, iCloud, and similar services are insecure. They generally have extensive controls – both technical and policy restrictions – to keep employees from snooping. But such services aren’t suitable for all users in all cases – especially for businesses or governmental organizations that are contractually or legally obligated to keep certain data private. Now let’s think beyond consumer services, about the enterprise side. Salesforce? Yep – of course they can read your data (unless you add an encryption proxy). SaaS services nearly always – so they can do stuff with your data. PaaS? Same deal (again, unless you do the encryption yourself). IaaS? Of course – your instance needs to boot up somehow, and if you want attached volumes to be encrypted you have to do it yourself. The main thing for Securosis readers to understand is that the vast majority of consumer and enterprise cloud services that mention encryption or offer encryption options, manage your keys for you, and have full access to your data. Why offer encryption at all then, if it doesn’t really improve security? Compliance. It wipes out one risk (lost hard drives), and reduces compliance scope for physical handling of the storage media. It also looks god on a checklist. Take Amazon S3 – Amazon is really clear that although you can encrypt data, they can still read it. I suppose the only reason I wrote this post and the article is because I’m sick of the “iWhatever service can read your data” non-stories that seem to crop up all the time. Duh. Share:

Rich here… Normally I like to open the Summary with a bit of something from my personal life. Some sort of anecdote with a message. In other words, I blatantly ripped off Mike’s format for the Security Incite… long before he took over half the company. (With Mike, even a partnership can probably be defined as a hostile takeover, based solely on his gruff voice and honesty of opinion). Heck, I can’t even remember any good anecdotes from the CCSK cloud security class Adrian and I taught last week in San Jose. Even when we hooked up with Richard Baker and our own James Arlen for dinner, I think half the conversation was about my and Jamie’s recent family trips to dinner. And that stripmall Thai place is probably better than the fanciest one here in Phoenix. I don’t even have any good workout anecdotes. I’m back on the triathlon wagon and chugging along. Although I did get a really cool new heart rate monitor/GPS that I’m totally in love with. (The Garmin 910XT, which is friggin’ amazing). I probably need to pick a race to prep for, but am otherwise enjoying being healthy and relatively uninjured, and not getting run over by cars on my bike rides. The kids are still cute and the older one is finally getting addicted to the iPad (which I encourage, although it is making normal computers really frustrating for her to use). They talk a lot, are growing too fast, and are far more interesting than anything else in my life. By nope, no major life lessons in the past few weeks that I can remember. Although there are some clear analogies between having kids and advanced persistent threats. Especially if you have daughters. And work? The only lesson there is to be careful what you wish for, as I fail, on a daily basis, to keep up with my inbox. Never mind my actual projects. But business is good, some very cool research is on the way, and it’s nice to have a paycheck. And I swear the Nexus isn’t vaporware. It’s actually all torn apart as we hammer in a ton of updates based on the initial beta feedback. In other words… life doesn’t suck. I actually enjoy it, and am amazed I get to write this on my iPad while sitting outside in perfect weather at a local restaurant. Besides, this is a security blog – if you’re reading it for life messages you need to get out more. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted by Ars Technica on iCloud privacy and security. Rich, again over at Ars, but this time on iPhone forensics. Favorite Securosis Posts Adrian Lane: iOS Data Security: Managed Devices. Both the post and the banter are quality. Mike Rothman: Defining Your iOS Data Security Strategy. Really liked this series by Rich. Great work and very timely. BYOD and other mobile security issues are the #1 concern of the folks I’m talking to during my travels. Rich: Vulnerability Management Evolution: Scanning the Infrastructure. Yes, we still have to deal with this stuff in 2012. Other Securosis Posts Incite 4/4/2012: Travel the Barbarian. Watching the Watchers: Protect Credentials. Vulnerability Management Evolution: Introduction. iOS Data Security: Securing Data on Partially-Managed Devices. Understanding and Selecting DSP: Core Features. Understanding and Selecting DSP: Extended Features. Favorite Outside Posts Adrian Lane: Hash Length Extension Attacks. Injection attack on MAC check. Interesting. Mike Rothman: Choosing Between Making Money and Doing What You Love. The answer? Both. Even if you can’t make your passion a full time gig, working at it a little every day seems to make folks happy. Good to know. Dave Lewis: Too many passwords? Just one does the trick. Rich: DNS Changer. Possibly the most important thing you’ll read this year. Research Reports and Presentations Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Top News and Posts VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation. Wig Wam Bam. & Citrix and CloudStack Citrix intends to join and contribute to Apache Software Foundation. This isn’t security specific, but it is big. Global Payments: Rumor and Innuendo. GPN is saying there was no POS or merchant account hacking, so this was a breach of their systems. Flashback Trojan Compromises Macs. Dear FBI, Who Lost $1 Billion? Oh my goodness, does Adam nail it with this one. Major VMWare vulnerability. Incredible research here. An only semi-blatant advertisement for our friend Mr. Mortman at EnStratus. ZeuS botnet targets USAirways passengers. (No, not while they’re on the plane… yet). Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Ryan, in response to iOS Data Security: Managed Devices. Is it nicer to say “captive network” or “traffic backhauling”? That said, nice post, and definitely part of a strategy I’ve seen work, although the example that leaps to mind is actually a security products company Share:

Now that we’ve covered the different data security options for iOS it’s time to focus on building a strategy. In many ways figuring out the technology is the easy part of the problem – the problems start when you need to apply that technology in a dynamic business environment, with users who have already made technology choices. Factors Most organizations we talk with – of all sizes and in all verticals – are under intense pressure to support iOS, to expand support of iOS, or to wrangle control over data security on iDevices already deployed and in active use. So developing your strategy depends on where you are starting from as much as on your overall goals. Here are the major factors to consider: Device ownership Device ownership is no longer a simple “ours or theirs”. Although some companies are able to maintain strict management of everything that connects to their networks and accesses data, this is becoming the exception more than the rule. Nearly all organizations are being forced to accept at least some level of employee-owned device access to enterprise assets whether that means remote access for a home PC, or access to corporate email on an iPad. The first question you need to ask yourself is whether you can maintain strict ownership of all devices you support – or if you even want to. The gut instinct of most security professionals is to only allow organization-owned devices, but this is rarely a viable long-term strategy. On the other hand, allowing employee-owned devices doesn’t require you to give up on enterprise ownership completely. Many of the data security options we have discussed work in a variety of scenarios. Here’s how to piece together your options: Employee owned devices: Your options are either partially managed or unmanaged. With unmanaged you have few viable security options and should focus on sandboxed messaging, encryption, and DRM apps. Even if you use one of these options, it will be more secure if you use even minimal partial management to enable data protection (by enforcing a passcode), enable remote wipe, and installing an enterprise digital certificate. The key is to sell this option to users, as we will detail below. Organization owned devices: These fall into two categories – general and limited use. Limited use devices are highly restricted and serve a single purpose; such as flight manuals for pilots, mobility apps for health care, or sales/sales engineering support. They are locked down with only necessary apps running. General use devices are issued to employees for a variety of job duties and support a wider range of applications. For data security, focus on the techniques that manage data moving on and off devices – typically managed email and networking, with good app support for what they need to get their jobs done. If the employee owns the device you need to get their permission for any management of it. Define simple clear policies that include the following points: It is the employee’s device, but in exchange for access to work resources the employee allows the organization to install a work profile on the device. The work profile requires a strong passcode to protect the device and the data stored on it. In the event the device is lost or stolen, you must report it within [time period]. If there is reasonable belief the device is at risk [employer] will remotely wipe the device. This protects both personal and company data. If you use a sandboxed app that only wipes itself, specify that here. If you use a backhaul network, detail when it is used. Devices cannot be shared with others, including family. How the user is allowed to backup the device (or a recommended backup option). Emphasize that these restrictions protect both personal and organizational data. The user must understand and accept that they are giving up some control of their device in order to gain access to work resources. They must sign the policy, because you are installing something on their personal device, and you need clear evidence they know what that means. Culture Financial services companies, defense contractors, healthcare organizations, and tech startups all have very different cultures. Some expect and accept much more tightly restricted access to employer resources, while others assume unrestricted access to consumer technology. Don’t underestimate culture when defining your strategy – we have presented a variety of options on the data security spectrum, and some may not work with your particular culture. If more freedom is expected look to sandboxed apps. If management is expected, you can support a wider range of work activities, with your tighter device control. Sensitivity of the data Not every organization has the same data security needs. There are industries with information that simply shouldn’t be allowed onto a mobile device with any chance of loss. But most organizations have more flexibility. The more sensitive the data, the more it needs to be isolated (or restricted from being on the device). This ties into both network security options (including DLP to prevent sensitive data from going to the device) and messaging/file access options (such as Exchange ActiveSync and sandboxed apps of all flavors). Not all data is equal. Assess your risk and then tie it back into an appropriate technology strategy. Business needs and workflow If you need to exchange documents with partners, you will use different tools than if you only want to allow access to employee email. If you use cloud storage or care about document-level security, you may need a different tool. Determine what the business wants to do with devices, then figure out which components you need to support that. And don’t forget to look at what they are already doing, which might surprise you. Existing infrastructure If you have backhaul networks or existing encryption tools that may incline you in a particular direction. Document storage and sharing technologies (both internal and cloud) are also likely to influence your decision. The trick is to follow the workflow. As we mentioned previously, you should map out existing