Research

It was a Mr. Mom weekend, so I particularly appreciated settling in at the coffee shop on Monday morning and getting some stuff done. And it wasn’t just trucking the kids around to their various activities. It was a big weekend for all of us to catch up on work. XX1 has the CRCT standardized test this week, which is a big deal in GA, so there was much prep for that. Both XX2 and Boy have How to presentations in class this week. So they each had to write and practice a presentation. And I had to finish up our taxes and update the Securosis financials. With the Boss in absentia, I was juggling knives trying to get everything done. I look back on an intense but fun weekend. But when you spend a large block of time with kids, they inevitably surprise you with their interrogation… I mean questions. I was wearing my Hot Truck t-shirt (pictured at right), and the Boy was fascinated. What’s a Hot Truck? Is it hot? That was just the beginning of the questioning, so the Boy needed a little context. The Hot Truck is an institution for those who went to Cornell. Basically a guy made French Bread pizzas in a truck parked every night right off campus. Conveniently enough the truck parked around the corner from my fraternity house, and it was clearly the preferred late night meal after a night of hard partying. At any time of year you had folks milling around the truck waiting for their order. Of course the truck itself was pretty cool. It was basically an old box truck fitted with a pizza oven. The city set up a power outlet right on the street and he’d drive up at maybe 10pm, plug in, and start cooking. Things didn’t get exciting until 1 or 2 in the morning. Then the line would be 10-15 deep and the money guy would write your order on a paper bag. No name, nothing else. Just your order. Obviously there were plenty of ways to game such a sophisticated system. You could sneak a peek at the list and then say the sandwich was yours when it came up. Then wait until the real owner of the sandwich showed up and tried to figure out what happened while you munched on their food. The truck was there until 4am or so – basically until everyone got served. Over time, you got to know Bob (the owner) and he’d let you inside the truck (which was great on those 10-degree winter nights) to chat. You’d get your sandwich made sooner or could just take one of the unclaimed orders. He must have loved talking to all those drunk fools every night. But best of all was the shorthand language that emerged from the Hot Truck. You could order the PMP (Poor Man’s Pizza), MBC (meatballs and cheese), RoRo (roast beef with mushrooms), or even a Shaggy (a little bit of everything) – named after a fraternity brother of mine. And then you’d put on the extras, like Pep (pepperoni) or G&G (grease the garden – mayo and lettuce). All on a french bread pizza. My favorite was the MBC Pep G&G. Between the Hot Truck and beer it’s no wonder I gained a bunch of weight every year at school. But all things end and Bob sold the Truck a few years ago. It was bought by a local convenience store and they still run the truck, as well as serve the sandwiches in their store in downtown Ithaca. It’s just not the same experience though – especially since I don’t eat meatballs anymore. But the memories of Hot Truck live on, and I even have the t-shirt to prove it. –Mike Photo credits: “Hot Truck T-Shirt” taken by Mike Rothman Heavy Research We’re back at work on a variety of our blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS to get all our content in its unabridged glory. Vulnerability Management Evolution Scanning the Application Layer Watching the Watchers (Privileged User Management) Monitor Privileged Users Clouds Rolling In Understanding and Selecting DSP Use Cases Malware Analysis Quant Index of Posts Incite 4 U Stone cold responders: I recently did a session with a dozen or so CISOs at an IANS Forum, and one of the topics was incident response. I started to talk about the human toll of high-pressure incident response, and got a bunch of blank stares. Of course we dug in, and the bigger companies with dedicated response staff said they staff incident response teams with even-keeled folks. The kind who don’t get too excited or depressed or much of anything. Which kind of aligns with Lenny Z’s post on the kind of personality that detects security issues early. Seems anxious folks on edge all the time may not have an effective early warning system. Just more evidence that you need the right folks in the right spots for any chance at success. – MR PCI: Living on borrowed time? Bob Carr of Heartland Payments says Anyone that thinks they’re not going to be breached is naive. This interview, posted just days after Heartland’s financial settlement details went public, reinforces the notion that – just like cockroaches are the only survivors of a nuclear holocaust, only lawyers win in lawsuits. It was expensive for Heartland, and CardSystems Solutions did not survive. Which is topical in light of the Global Payments breach, which illustrates the risk to financial companies when Visa is offering to forgo PCI audits if a majority of merchant transactions originate from EMV terminals. Keep in mind that the breach to Global Payments – or Heartland for that matter – and fraud managed by cloning credit cards are totally separate. So time when merchants and payment processors should more aggressively look at security and breach preparedness as Mr. Carr advocates… Visa is backing off on audits to boost EMV. Some will say this is an exchange for back office security for

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:

As much as we enjoy being the masters of the obvious, we don’t really need to discuss the move to cloud computing. It’s happening. It’s disruptive. Blah blah blah. People love to quibble about the details but it’s obvious to everyone. And of course, when the computation and storage behind your essential IT services might not reside in a facility under your control, things change a bit. The idea of a privileged user morphs in the cloud context, by adding another layer of abstraction via the cloud management environment. So regardless of your current level of cloud computing adoption, you need to factor the cloud into your PUM (privileged user management) initiative. Or do you? Let’s play a little Devil’s advocate here. When you think about it, isn’t cloud computing just more happening faster? You still have the same operating systems running as guests in public and/or private clouds, but with a greatly improved ability to spin up machines, faster than ever before. If you are able to provision and manage the entitlements of these new servers, it’s all good, right? In the abstract, yes. But the same old same old doesn’t work nearly as well in the new regime. Though we do respect the ostrich. Unfortunately burying your head in the sand doesn’t really remove the need to think about cloud privileged users. So let’s walk through some ways cloud computing differs fundamentally than the classical world of on-premise physical servers. Cloud Risks First of all, any cloud initiative adds another layer of management abstraction. You manage cloud resources though either a virtualization console (such as vCenter or XenCenter) or a public cloud management interface. This means a new set of privileged users and entitlements which require management. Additionally, this cloud stuff is (relatively) new, so management capability lags well behind a traditional data center. It’s evolving rapidly but hasn’t yet caught up with tools and processes for management of physical servers on a local physical network – and that immaturity poses a risk. For example, without entitlements properly configured, anyone with access to the cloud console can create and tear down any instance in the account. Or they can change access keys, add access or entitlements, change permissions, etc. – for the entire virtual data enter. Again, this doesn’t mean you shouldn’t proceed and take full advantage of cloud initiatives. But take care to avoid unintended consequences stemming from the flexibility and abstraction of the cloud. We also face a number of new risks driven by the flexibility of provisioning new computing resources. Any privileged user can spin up a new instance, which might not include proper agentry & instrumentation to plug into the cloud management environment. You don’t have the same coarse control of network access we had before, so it’s easier for new (virtual) servers to pop up, which means it’s also easier to be exposed accidentally. Management and security largely need to be implemented within the instances – you cannot rely on the cloud infrastructure to provide them. So cloud consoles absolutely demand suitable protection – at least as much as the most important server under their control. You will want to take a similar lifecycle approach to protecting the cloud console as you do with traditional devices. The Lifecycle in the Clouds To revisit our earlier research, the Privileged User Lifecycle involves restricting access, protecting credentials, enforcing entitlements, and monitoring P-user activity – but what does that look like in a cloud context? Restrict Access (Cloud) As in the physical world, you have a few options for restricting access to sensitive devices, which vary dramatically between private and public clouds. To recap: you can implement access controls within the network, on the devices themselves (via agents), or by running all connections through a proxy and only allowing management connections from the proxy. Private cloud console: The tactics we described in Restrict Access generally work, but there are a few caveats. Network access control gets a lot more complicated due to the inherent abstraction of the cloud. Agentry requires pre-authorized instances which include properly configured software. A proxy requires an additional agent of some kind on each instance, to restrict management connections to the proxy. That is actually as in the traditional datacenter – but now it must be tightly integrated with the cloud console. As instances come and go, knowing which instances are running and which policy groups each instance requires becomes the challenge. To fill this gap, third party cloud management software providers are emerging to add finer-grained access control in private clouds. Public cloud console: Restricting network access is an obvious non-starter in a public cloud. Fortunately you can set up specific security groups to restrict traffic and have some granularity on which IP addresses and protocols can access the instances, which would be fine in a shared administrator context. But you aren’t able to restrict access to specific users on specific devices (as required by most compliance mandates) at the network layer, because you have little control over the network in a public cloud. That leaves agentry on the instances, but with little ability to stop unauthorized parties from accessing instances. Another less viable option is a proxy, but you can’t really restrict access per se – the console literally lives on the Internet. To protect instances in a public cloud environment, you need to insert protections into other segments of the lifecycle. Fortunately we are seeing some innovation in cloud management, including the ability to manage on demand. This means access to manage instances (usually via ssh on Linux instances) is off by default. Only when management is required does the cloud console open up a management port(s) via policy, and only for authorized users at specified times. That approach address a number of the challenges of always on and always accessible cloud instances, and so it’s a promising model for cloud management. Protect Credentials (Cloud) When we think about protecting credentials for cloud computing resources, we use got an expanded concept of credentials. We now need to worry about three types of credentials: Credentials for the cloud console(s) Credentials

Happy Friday the 13th! I was thinking about superstition and science today, so I was particularly amused to notice that it’s Friday the 13th. Rich and I are both scientists of sorts; we both eschew superstition, but we occasionally argue about science. What’s real and what’s not. What’s science, what’s pseudoscience, and what’s just plain myth. It’s interesting to discuss root causes and what forces actually alter our surroundings. Do we have enough data to make an assertion about something, or is it just a statistical anomaly? I’m far more likely to jump to conclusions about stuff based on personal experience, and he’s more rigorous with the scientific method. And that’s true for work as well as life in general. For example he still shuns my use of Vitamin C, while I’m convinced it has a positive effect. And Rich chides as I make statements about things I don’t understand, or assertions that are completely ‘pseudoscience’ in his book. I’ll make an off-handed observation and he’ll respond with “Myth Busters proved that’s wrong in last week’s show”. And he’s usually right. We still have a fundamental disagreement about the probability of self-atomizing concrete, a story I’d rather not go into – but regardless, we are both serious tech geeks and proponents of science. I regularly run across stuff that surprises me and challenges my fundamental perception of what’s possible. And I am fascinated by those things and the explanations ‘experts’ come up with for them – usually from people with a financial incentive. Hawking anything from food to electronic devices by claiming benefits we cannot measure, or for which we don’t have science which could prove or disprove their clams. To keep things from getting all political or religious, I restrict my examples to my favorite hobby: HiFi. I offer power cords as an example. I’ve switched most of the power cords to my television, iMac, and stereo to versions that run $100 to $300. Sounds deranged, I know, to spend that much on a piece of wire. But you know what? The colors on the television are deeper, more saturated, and far less visually ‘noisy’. Same for the iMac. And I’m not the only one who has witnessed this. It’s not subtle, and it’s completely repeatable. But I am at a loss to understand how the last three feet of copper between the wall socket and the computer can dramatically improve the quality of the display. Or the sound from my stereo. I can see it, and I can hear it, but I know of no test to measure it and I just don’t find the explanations of “electron alignment” plausible. Sometimes it’s simply that nobody thought to measure stuff they should have because theoretically it shouldn’t matter. In college I thought most music sounded terrible and figured I had simply outgrown the music of my childhood. Turns out that in the 80s, when CDs were born, CD players introduced several new forms of distortion, and some of them were unmeasurable. Listener fatigue became common, many people getting headaches as a result of these poorly created devices. Things like jitter, power supply noise, noise created by different types of silicon gates and capacitors, all producing sonic signatures audible to the human ear. Lots of this couldn’t be effectively measured but will send you running from the room. Fortunately over the last 12 years or so audio designers have become aware of these new forms of distortion, and they now have devices that can measure them to one degree or another. I can even hear significant differences with various analog valves (i.e. ‘tubes’) where I cannot measure electrical differences. Another oddity I have found is with vibration control devices. I went to a friend’s house and found his amplifiers and DVD players suspended high in the air on top of maple butcher blocks, which sat on top of what looked like a pair of hockey pucks separated by a ball bearing. The maple blocks are supposed to both absorb vibration and avoid electromagnetic interference between components. And we did several A/B comparisons with and without each, but it was the little bearings that made a clear and noticeable difference in sound quality. The theory is that high frequency vibrations, which shake the electronic circuits of the amps and CD players, decrease resolution and introduce some form of distortion. Is that true? I have no clue. Do they work? Hell yes they do! I know that my mountain bike’s frame was designed to alter the tube circumference and wall thicknesses as a method of dampening vibrations, and there is an improvement over previous generations of bike frames, albeit a subtle one. The reduction in vibrations on the bike can easily be measured, as can the vibrations and electromagnetic interference between A/V equipment. But the vibrational energy is so vanishingly small that it should never make a difference to audio quality. Then there are the environmental factors that alter the user’s perception of events. Yeah, drugs and alcohol would be an example, but sticking to my HiFi theme: a creme that makes your iPod sound better. Works by creating a positive impression with the user. Which again borders on the absurd. An unknown phenomena, or snake oil? Sometimes it’s tough to tell superstition from science. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading paper on User Activity Monitoring. Rich’s excellent Macworld article on the Flashback malware. Adrian’s Dark Reading post on reverse database proxies. Favorite Securosis Posts Adrian Lane: The Myth of the Security-Smug Mac User. We get so many ‘news’ items, like how Android will capture the tablet market in 2015, or how Apple’s market share of smartphones is dwindling, or how smug Apple users will get their ‘comeuppance’ for rejecting AV solutions, that you wonder who’s coming up with this crap. Mac users may not have faith in AV to keep them secure, but they know eventually Macs will be targeted just as Windows has been. And I’m fairly certain most hackers run on

I figured an afternoon flight to the midwest would be reasonably peaceful. I was wrong. Things started on the wrong foot when I got an email notification from Delta that the flight was delayed, even though it wasn’t. The resulting OJ sprint through the terminal to make the flight was agitating. Then the tons of screaming kids on the flight didn’t help matters. I’m thankful for noise isolating headphones, that’s for sure. But seeing the parents walking their kids up and down the aisle and dealing with the pain of ascent and descent on the kids’ eardrums got me thinking about my own situation. As I mentioned, I was in Italy last week teaching our CCSK course, but the Boss took the kids up north for spring break to visit family. She flew with all of the kids by herself. 5 years ago that never would have happened. We actually didn’t fly as a family for years because it was just too hard. With infant/toddler twins and one three years older, the pain of getting all the crap through the airport and dealing with security and car seats and all the other misery just wasn’t worth it. It was much easier to drive and for anything less than 6-7 hours, it was probably faster to load up the van. The Boss had no problems on the flight. The kids had their iOS devices and watched movies, played games, ate peanuts, enjoyed soda, and basically didn’t give her a hard time at all. They know how to equalize their ears, so the pain wasn’t an issue, and they took advantage of the endless supply of gum they can chew on a flight. So that problem isn’t really a problem any more. As long as they don’t go on walkabout through the terminal, it’s all good. But it doesn’t mean we haven’t exchanged one problem for another. XX1 has entered the tween phase. Between the hormonally driven attitude and her general perspective that she knows everything (yeah, like every other kid), sometimes I long for the days of diapers. At least I didn’t have a kid challenging stuff I learned the hard way decades ago. And the twins have their own issues, as they deal with friend drama and the typical crap around staying focused. When I see harried parents with multiples, sometimes I walk up and tell them it gets easier. I probably shouldn’t lie to them like that. It’s not easier, it’s just different. You constantly exchange one problem for another. Soon enough XX1 will be driving and that creates all sorts of other issues. And then they’ll be off to college and the rest of their lives. So as challenging as it is sometimes, I try to enjoy the angst and keep it all in perspective. If life was easy, what fun would it be? -Mike Photo credits: “Problems are Opportunities” originally uploaded by Donna Grayson Heavy Research We’re 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 access all of our content in its unabridged glory. Vulnerability Management Evolution Scanning the Infrastructure Scanning the Application Layer Watching the Watchers (Privileged User Management) Enforce Entitlements Monitor Privileged Users Understanding and Selecting DSP Extended Features Administration Malware Analysis Quant Index of Posts Incite 4 U Geer on application security: no silent failures Honestly, it’s pointless to try to summarize anything Dan Geer says. A summary misses the point. It misses the art of his words. And you’d miss priceless quotes like “There’s no government like no government,” and regarding data loss, “if I steal your data, then you still have them, unlike when I steal your underpants.” Brilliant. Just brilliant. So read this transcript of Dan’s keynote at AppSecDC and be thankful Dan is generous enough to post his public talks. Let me leave you my main takeaway from Dan’s talk: “In a sense, our longstanding wish to be taken seriously has come; we will soon reflect on whether we really wanted that.” This is an opportunity to learn from a guy who has seen it all in security. Literally. Don’t squander it. Take the 15 minutes and read the talk. – MR AppSec trio: Fergal Glynn of Veracode has started A CISO’s Guide to Application Security, a series on Threatpost. And it’s off to a good start, packed with a lot of good information, but the ‘components’ are all blending together. Secure software development, secure operations, and a software assurance program are three different things; and while they go hand in hand if you want a thorough program, it’s easier to think about them as three legs of the proverbial stool. Make no mistake, I have implemented secure coding techniques based purely on threat modeling because we had no metrics – or even idea of what metrics were viable – to do an assurance program. I’ve worked in finance, with little or no code development, relying purely on operational controls around pre-deployment and deployment phases on COTS software. At another firm I implemented metrics and risk analysis to inspire the CEO to allow secure code development to happen. So while these things get blurred together under the “application security” umbrella, remember they’re three different sets of techniques and processes, with three slightly different – and hopefully cooperating – audiences. – AL It’s the economy, stupid: One of the weirdest things I’ve realized over years in the security industry is how much security is about economics and psychology, not about technology. No, I’m not flying off the deep end and ignoring the tech (I’m still a geek, after all), but if you want to make big changes you need to focus on things that affect the economics, not how many times a user clicks on links in email. One great example is the new database the government and cell phone providers are setting up to track stolen phones. Not only will they keep track of the stolen phones, they will make sure they can’t be

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

It’s funny to contrast this April to last April, at least as an NFL fan. Last year the lockout was in force, the negotiations stalled, and fans wondered how billionaires could argue with millionaires when the economy was in the crapper. Between the Peyton Manning lottery, the upcoming draft, and the Saints Bounty situation, there hasn’t been a dull moment for pro football fans since the Super Bowl ended. Speaking of the Saints, even after suspensions and fines, more nasty aspects of the story keep surfacing. Last week, we actually heard Gregg Williams, Defensive Coordinator of the Saints, implore his guys to target injured players, ‘affect’ the head, and twist ankles in the pile. Kind of nauseating. OK, very nauseating. I guess it’s true that most folks don’t want to see how the sausage is made – they just want to enjoy the taste. But the disclosure was anything but clean, Sean Pamphilon, the director who posted the audio, did not have permission to post it. He was a guest of a guest at that meeting, there to capture the life of former Saints player Steve Gleason, who is afflicted with ALS. The director argues he had the right. The player (and the Saints) insist he didn’t. Clearly the audio put the bounty situation in a different light for fans of the game. Before it was deplorable, but abstract. After listening to the tape, it was real. He really said that stuff. Really paid money for his team to intentionally hurt opponents. Just terrible. But there is still the dilemma of posting the tape without permission. Smart folks come down on both sides of this discussion. Many believe Pamphilon should have abided by the wishes of his host and not posted the audio. He wouldn’t have been there if not for the graciousness of both Steve Gleason and the Saints. But he was and he clearly felt the public had a right to know, given the history of the NFL burying audio & video evidence of wrongdoing (Spygate, anyone?). Legalities aside, this is a much higher profile example of the same responsible disclosure debate we security folks have every week. Does the public have a need to know? Is the disclosure of a zero day attack doing a public service? Or should the researcher wait until the patch goes live, when they get to enjoy a credit buried in the patch notice? Cynically, some folks disclosing zero-days are in it for the publicity. Sure, they can blame unresponsive vendors, but at the end of the day, some folks seek the spotlight by breaking a juicy zero-day. Likewise, you can make a case that Pamphilon was able to draw a lot of attention to himself and his projects (past, current, and future) by posting the audio. Obviously you can’t buy press coverage like that. Does that make it wrong – that the discloser gets the benefit of notoriety? There is no right or wrong answer here. There are just differing opinions. I’m not trying to open Pandora’s box and entertain a lot of discussion on responsible disclosure. Smart people have differing opinions and nothing I say will change that. My point was to draw the parallel between the Saints bounty tape disclosure and disclosing zero day attacks. Hopefully that provides some additional context for the moral struggles of researchers deciding whether to go public with their findings or not. Share:

Mary Ann Davidson’s recent post Pain Comes Instantly has been generating a lot of press. It’s being miscast by some of the media outlets as trashing PCI Data Security Standard, but it’s really about the rules for vendors who want to certify commercial payment software and related products. The debate is worth considering, so I recommend giving it a read. It’s a long post, but I encourage you to read it all the way through before forming opinions, as she makes many arguments and provides some allegories along the way. In essence she challenges the PCI Council on a particular requirement in the Payment Application Vendor Release Agreement (VRA), part of each vendor’s contractual agreement with the PCI Council to get their applications certified as PCI compliant. The issue is over software vulnerability disclosure. Paraphrasing the issue at hand, let’s say Oracle becomes aware of a security bug. Under the terms of the agreement, Oracle must disseminate the information to the Council as part of the required information disclosure process. Her complaint is that the PCI Council insists on its right to leak (‘share’) this information even when Oracle has not yet provided a fix. Mary Ann argues that in this case the PCI Council is harming Oracle’s customers (who are also PCI Council customers) by making the vulnerability public. Hackers will of course exploit the vulnerability and try to breach the payment systems. The real point of contention is that the PCI Council may decide to share this information with QSAs, partners, and other organizations, so those security experts can better protect themselves and PCI customers based upon this information. Oracle’s position is that these QSAs and others who may receive information from the Council are not qualified to make use the information. And second, the more people know about the vulnerability, the more it likely it is to leak. I don’t have a problem with those points. I totally agree that if you tell thousands of people about the vulnerability, it’s as good as public knowledge. And it’s probably safe to wager that only a small percentage of Oracle customers have the initiative or knowledge to take vulnerability information and craft it into effective protection. Even if a customer has Oracle’s database firewall, they won’t be able to create a rule to protect the database from this vulnerability information. So from that perspective, I agree. But it’s a limited perspective. Just because few Oracle customers can generate a fix or a workaround doesn’t mean that a fix won’t or can’t be made available. Oracle customers have contributed workarounds in the past. Even if an individual customer can’t help themselves, others can – and have. But here’s my real problem with that post: I am having trouble finding a substantial difference between her argument and the whole responsible disclosure debate. What’s the real difference from a security researcher finding an Oracle vulnerability? The information is outside Oracle’s control in both cases, and there is a likelihood of public disclosure. It’s something a determined hacker may discover, or have already discovered. It’s in Oracle’s best interest to fix the problem fast before the rest of the world finds out. Historically the problem is that vendors, unless they have been publicly shamed into action, don’t react quickly to security issues. Oracle, among other vendors, has often been accused of siting on vulnerabilities for months – even years – before addressing them. Security researchers for years told basically the same story about Oracle flaws they found, which goes something like this: We have discovered a security flaw in Oracle. We told Oracle about it, and gave them details on how to reproduce it and some suggestions for how to fix it. Oracle a) never fixed it, b) produced a half-assed fix that causes other issues, or c) waited 9, 12, or 18 months before patching the issue – and that was only after I announced the bug to the world at the RSA/DefCon/Black Hat/OWASP conference. I gave Oracle information that anyone could discover, and did not ask for any compensation, and Oracle tried to sue me when I disclosed the vulnerability after 12 months. I’m not Oracle bashing here – it’s an industry-wide issue – but my point that with disclosure, timing matters… a lot. Since the Payment Application Vendor Release Agreement simply states you will ‘promptly’ inform the PCI Council of vulnerabilities, Oracle has a bit of leeway. Maybe ‘prompt’ means 30 days. Heck, maybe 60. That should be enough time to get a patch to those customers using certified payment products – or whatever term the PCI council uses for vetted but not guaranteed software. If a vendor is a bit tardy with getting detailed information to the PCI Council while they code and test a fix, I don’t think the PCI council will complain too much, so long as they are protected from liability. But make no mistake – timing is a critical part of this whole issue. Timing – particularly the lack of ‘prompt’ responses from Oracle – is why the security research community remains pissed-off and critical to this day. Share:

Today’s post focuses on the administering Database Security Platforms. Conceptually DSP is pretty simple: collect data from databases, analyze it according to established rules, and react when a rule has been violated. The administrative component of every DSP platform follows these three basic tasks: data management, policy management, and workflow management. In addition to these three basic functions, we also need to administer the platform itself, as we do with any other application platform. As we described in our earlier post on DSP technical architecture, DSP sends all collected data to a central server. The DAM precursors evolved from single servers, to two-tiered architectures, and finally into a hierarchal model, in order to scale up to enterprise environments. The good news is that system maintenance, data storage, and policy management are all available from a single console. While administration is now usually through a browser, the web application server that performs the work is built into the central management server. Unlike some other security products, not much glue code or browser tricks is required to stitch things together. System Management User Management: With access to many different databases, most filtering and reporting on sensitive data, user management is critical for security. Establishing who can make changes to policies, read collected data, or administer the platform are all specialized tasks, and these groups of users are typically kept separate. All DSP solutions offer different methods for segregating users into different groups, each with differing granularity. Most of the platforms offer integration with directory services to aid in user provisioning and assignment of roles. Collector/Sensor/Target Database Management: Agents and data collectors are managed from the central server. While data and policies are stored centrally, the collectors – which often enforce policy on the remote database – must periodically synch with the central server to update rules and settings. Some systems require the administrator to ‘push’ rules out to agents or remote servers, while others synch automatically. Systems Management: DSP is, in and of itself, and application platform. It has web interfaces, automated services, and databases like most enterprise applications. As such it requires some tweaking, patching, and configuration to perform its best. For example, the supporting database may need pruning to clear out older data, vendor assessment rules require updates, and the system may need additional resources for data storage and reports. The system management interface is provided via a web browser, but only available to authorized administrators. Data Aggregation & Correlation The one characteristic Database Activity Monitoring solutions share with log management, and even Security Information and Event Management, tools is their ability to collect disparate activity logs from a variety of database management systems. They tend to exceed the capabilities of related technologies in their ability to go “up the stack” in order to gather deeper database activity application layer data, and in their ability to correlate information. Like SIEM, DSP aggregates, normalizes, and correlates events across many heterogenous sources. Some platforms even provide an optional ‘enrichment’ capability by linking audit, identity and assessment data to event records. For example, providing both ‘before’ and ‘after’ data values for a suspect query. Despite central management and correlation features, the similarities with SIEM end there. By understanding the Structured Query Language (SQL) of each database platform, these platforms can interpret queries and understand their meaning. While a simple SELECT statement might mean the same thing across different database platforms, each database management system (DBMS) is full of its own particular syntax. DSP understands the SQL for each platform is able to normalize events so the user doesn’t need to know the ins and outs of each DBMS. For example, if you want to review all privilege escalations on all covered systems, a DAM solution will recognize those events, regardless of platform and present a complete report, without you having to understand the SQL. A more advanced feature is to then correlate activity across different transactions and platforms, rather than looking only at single events. For example, some platforms recognize a higher than normal transaction volume by a particular user, or (as we’ll consider in policies) can link a privilege escalation event with a large SELECT query on sensitive data, which could indicate an attack. All activity is also centrally collected in a secure repository to prevent tampering or a breach of the repository itself. Since they collect massive amounts of data, DSPs must support automatic archiving. Archiving should support separate backups of system activity, configuration, policies, alerts, and case management; and encrypt under separate keys to support separation of duties. Policy Management All platforms come with sets of pre-packaged policies for security and compliance. For example, every product contains hundreds, if not thousands, of assessment policies that identify vulnerabilities. Most platforms come with pre-defined policies for monitoring standard deployments of databases behind major applications such as Oracle Financials and SAP. Built-in policies for PCI, SOX, and other generic compliance requirements are also available to help you jump-start the process and save many hours of policy building. Every single policy has the built-in capability of generating an alert if the rule is violated – usually through email, instant message or some other messaging capability. Note that every user needs to tune or customize a subset of pre-existing policies to match their environment, and create others to address specific risks to their data. They are still far better than starting from scratch. Activity monitoring policies include user/group, time of day, source/destination, and other important contextual options. And these policies should offer different analysis techniques based on attributes, heuristics, context, and content analysis. They should also support advanced definitions, such as complex multi-level nesting and combinations. If a policy violation occurs you can specify any number of alerting, event handling and reactive actions. Ideally, the platform will include policy creation tools that limit the need to write everything out in SQL or some other definition language; it’s much better if your compliance team does not need to learn SQL programming to create policies. You can’t avoid having to do some things

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: