Research

In our first post on Fact-based Network Security, we talked about the need to make decisions based on data, as opposed to instinct. Then we went in search of the context to know what’s important, because in order to prioritize effectively you need to know what presents the most value to your organization. Now let’s dig a little deeper into the next step, which is determining the operational metrics on which to base decisions. But security metrics can be a slippery slope. First let’s draw a distinction between outcome-based metrics and operational metrics. Outcomes are the issues central to business performance, and as such are both visible and important to senior management. Examples may include uptime/availability, incidents, disclosures, etc. Basically, outcomes are the end results of your efforts. Where you are trying to get to, or stay away from (for negative outcomes). We recommend you start by establishing some goals for improvement of these outcomes. This gives you an idea of what you are trying to achieve and defines success. To illustrate this we can examine availability as an outcome – it’s never bad to improve availability of key business systems. Of course we are simplifying a bit – availability consists of more than just security. But we can think about availability in the context of security, and count issues/downtimes due to security problems. Obviously many types of activities impact availability. Device configuration changes can cause downtime. So can vulnerabilities that result in successful attacks. Don’t forget application problems that may cause performance anomalies. Traffic spikes (perhaps resulting from a DDoS) can also take down business systems. Even seemingly harmless changes to a routing table can open up an attack path from external networks. That’s just scratching the surface. The good news is that you can leverage operational data to isolate the root causes of these issues. What kinds of operational data do we need? Configuration data: Tracking configurations of network and security devices can yield important information about attack paths through your network and/or exploitable services running on these devices. Change information: Understanding when changes and/or patches take place helps isolate when devices need to be checked or scanned again to ensure new issues have not been not introduced. Vulnerabilities: Figuring out the soft spots of any device can yield valuable information about possible attacks. Network traffic: Keeping track of who is communicating with whom can help baseline an environment, which is important for detecting anomalous traffic and deciding whether it requires investigation. Obviously as you go deeper into the data center, applications, and even endpoints, there is much more operational data that can be gathered and analyzed. But remember the goal. You need to answer the core question of “what to do first,” establishing priorities among a infinite number of possible activities. We want to focus efforts on the activities that will yield the biggest favorable impact on security posture. A simple structure for this comes from the Securosis Data Breach Triangle. In order to have a breach, you need data that someone wants, an exploit to expose that data, and an egress path to exfiltrate it. If you break any leg of the triangle, you prevent a successful breach. Data (Attack Path) If the attacker can’t see the data, they can’t steal it, right? So we can focus some of our efforts on ensuring direct attack paths don’t make it easy for an attacker to access the data they want. Since you know your most critical business systems and their associated assets, you can watch to make sure attack paths don’t develop which expose this data. How? Start with proper network segmentation to separate important data from unauthorized people, systems, and applications. Then constantly monitor your network and security devices to ensure attack paths don’t put your systems at risk. Operational data such as router and firewall configurations is a key source for this analysis. You can also leverage network maps and ongoing discovery activities to check for new paths. Any time there is a change to a firewall setting or a network device, revisit your attack path analysis. That way you ensure there’s no ripple effect from a change that opens an exposure. Think of it as regression testing for network changes. Given the complexity of most enterprise-class networks, this isn’t something you can do manually, and it’s most effective in a visual context. Yes, in this case a picture is worth a million log records. A class of analysis tools has emerged to address this. Some look at firewall and network configurations to build and display a topology of your network. These tools constantly discover new devices and keep the topology up to date. We also see evolution of automated penetration testing tools, which focus on continuously trying to find attack paths to critical data, without requiring a human operator. There is no lack of technology to help model and track attack paths. Regardless of the technology you select to analyze the attack paths, this is key to understanding what to fix first. If a direct path to important data results from a configuration change, you know what to do (roll it back!). Likewise, if a rogue access point emerges on a critical network (with a direct path to important data), you need to get rid of it. These are the kind of activities that make an impact and need to be prioritized. Exploit Even if an attack path exists, it may not be practical to exploit the target device. This is where server configuration, as well as patch and vulnerability monitoring, are very useful. Changes that happen outside of authorized maintenance windows tend to be suspicious, especially on devices either containing or providing access to important data. Likewise, the presence of an exploitable critical vulnerability should bubble to the top of the priority list. Again, if there is no attack path to the vulnerable device, the priority of fixing the issue is reduced. But overall you must track what needs to be fixed on

It’s hard to believe, but over the past 24 hours I’ve had 3 separate briefings with companies innovating in the area of anti-malware. Just ask them. Each started the discussion with the self-evident point that the existing malware detection model is broken. Then they each proceeded to describe (at a high level) how what they are doing isn’t anti-virus per se, but something different. Something that detects the new malware we are seeing. They didn’t want to replace the anti-malware engine. They just think they address the areas where traditional anti-malware sucks. Yeah, that’s a big job. These vendors are not wrong. The existing approach of largely signature-based engines, recently leveraging a cloud extension, is broken. Clearly we need a new approach. True innovation, as opposed to marketing innovation. It’s easy to shoot holes in AV, with its sub-50% detection rate. It’s hard to actually do something sustainably different. We don’t need to poke more holes in AV, we need something that works better. Having been in this business for 20 years or so, this isn’t the first time attacks have gotten ahead of detection. You could make the case that detection has never caught up. Each time, a new set of innovators emerges with new models and products and capabilities, seemingly built to address the latest and greatest attack. Right, solving yesterday’s problems tomorrow. But that’s nothing new. It’s the security business as we know it. The problem is separating the wheat from the chaff. One of the companies I spoke with seems to have a better mousetrap. Maybe it is. Maybe it isn’t. The point is that it’s not the same mousetrap. But it will be an uphill battle for these folks to get a hearing, because endpoint security vendors have been lying to customers for years, saying their products actually stop new attacks. Now customers are highly skeptical, and are not very open to trying something different. Customers have heard it all before. This is just another cycle, compounded by the incumbents trying to sound different, while entirely focused on milking their cash cows. They will pay lip service to innovation, they always do. In reality they are more focused on reducing their agents’ footprints and improving performance, because those are costing them deals – not on the fact that they can’t detect an eskimo in Alaska. Another factor is the total farce of anti-malware testing labs. It seems like another pops up every week, commissioned to say one vendor performs better than the others. Awesome. Granted I was born skeptical, but these guys are not helping me believe in anything. So what to do? Same as it ever was. Endpoint protection is one of many tactics that can help identify and eventually contain malware. Layers are still good. Though we do expect innovation over the next year, so keep your eyes open. There is a pony somewhere in there, it’s just not clear which one is it. The rest will go down in the annals of security history as snake oil. Same as it ever was. There is very little benefit in being early with these new products/companies right now, spending time figuring out what really works. In other words, if I have an incremental $10, I’m spending it on monitoring and incident response technologies. But you already knew that. Prevention has (mostly) failed us. You know that too. Until some new anti-malware widget is vetted as making a difference (by people you trust), spend your time figuring out what went wrong. There is no lack of material there. Share:

One of the great things about running around teaching classes is all the feedback and questions we get from people actively working on all sorts of different initiatives. With the CCSK (cloud security) class, we find that a ton of people are grappling with these issues in active projects and different things in various stages of deep planning. We don’t want to lose this info, so we will to blog some of the more interesting questions and answers we get in the field. I’ll skip general impressions and trends today to focus on some specific questions people in last week’s class in Washington, DC, were grappling with: We currently use XXX Database Activity Monitoring appliance, is there any way to keep using it in Amazon EC2? This is a tough one because it depends completely on your vendor. With the exception of Oracle (last time I checked – this might have changed), all the major Database Activity Monitoring vendors support server agents as well as inline or passive appliances. Adrian covered most of the major issues between the two in his Database Activity Monitoring: Software vs. Appliance paper. The main question for cloud )especially public cloud) deployments is whether the agent will work in a virtual machine/instance. Most agents use special kernel hooks that need to be validated as compatible with your provider’s virtual machine hypervisor. In other words: yes, you can do it, but I can’t promise it will work with your current DAM product and cloud provider. If your cloud service supports multiple network interfaces per instance, you can also consider deploying a virtual DAM appliance to monitor traffic that way, but I’d be careful with this approach and don’t generally recommend it. Finally, there are more options for internal/private cloud where you can route the traffic even back to a dedicated appliance if necessary – but watch performance if you do. How can we monitor users connecting to cloud services over SSL? This is an easy problem to solve – you just need a web gateway with SSL decoding capabilities. In practice, this means the gateway essentially performs a man in the middle attack against your users. To work, you install the gateway appliance’s certificate as a trusted root on all your endpoints. This doesn’t work for remote users who aren’t going through your gateway. This is a fairly standard approach for both web content security and Data Loss Prevention, but those of you just using URL filtering may not be familiar with it. Can I use identity management to keep users out of my cloud services if they aren’t on the corporate network? Absolutely. If you use federated identity (probably SAML), you can configure things so users can only log into the cloud service if they are logged into your network. For example, you can configure Active Directory to use SAML extensions, then require SAML-based authentication for your cloud service. The SAML token/assertion will only be made when the user logs into the local network, so they can’t ever log in from another location. You can screw up this configuration by allowing persistent assertions (I’m sure Gunnar will correct my probably-wrong IAM vernacular). This approach will also work for VPN access (don’t forget to disable split tunnels if you want to monitor activity). What’s the CSA STAR project? STAR (Security, Trust & Assurance Registry) is a Cloud Security Alliance program where cloud providers perform and submit self assessments of their security practices. How can we encrypt big data sets without changing our applications? This isn’t a cloud-specific problem, but does come up a lot in the encryption section. First, I suggest you check out our paper on encryption: Understanding and Selecting a Database Encryption or Tokenization Solution. The best cloud option is usually volume encryption for IaaS. You may also be able to use some other form of transparent encryption, depending on the various specifics of your database and application. Some proxy-based in-the-cloud encryption solutions are starting to appear. That’s it from this class… we had a ton of other questions, but these stood out. As we teach more we’ll keep posting more, and I should get input from other instructors as they start teaching their own classes. Share:

Our motivation for launching the Security Management 2.0 research project lies in the general dissatisfaction with SIEM implementations – which in some cases have not delivered the expected value. The issues typically result from failure to scale, poor ease of use, excessive effort for care and feeding, or just customer execution failure. Granted some of the discontent is clearly navel-gazing – parsing and analyzing log files as part of your daily job is boring, mundane, and error-prone work you’d rather not do. But dissatisfaction with SIEM is largely legitimate and has gotten worse, as system load has grown and systems have been subjected to additional security requirements, driven by new and creative attack vectors. This all spotlights the fragility and poor architectural choices of some SIEM and Log Management platforms, especially early movers. Given that companies need to collect more – not less – data, review and management just get harder. Exponentially harder. This post is not to focus on user complaints – that doesn’t help solve problems. Instead let’s focus on the changes in SIEM platforms driving users to revisit their platform decisions. There are over 20 SIEM and Log Management vendors in the market, most of which have been at it for 5-10 years. Each vendor has evolved its products (and services) to meet customer requirements, as well as provide some degree of differentiation against the competition. We have seen new system architectures to maximize performance, increase scalability, leverage hybrid deployments, and broaden collection via CEF and universal collection format support. Usability enhancements include capabilities for data manipulation; addition of contextual data via log/event enrichment; as well as more powerful tools for management, reporting, and visualization. Data analysis enhancements include expanding supported data types to include dozens of variants for monitoring, correlating/alerting, and reporting on change controls; configuration, application, and threat data; content analysis (poor man’s DLP) and user activity monitoring. With literally hundreds of new features to comb through, it’s important to recognize that not all innovation is valuable to you, and you should keep irrelevancies out of your analysis of benefits of moving to a new platform. Just because the shiny new object has lots of bells and whistles doesn’t mean they are relevant to your decision. Our research shows the most impactful enhancements have been the enhancements in scalability, along with reduced storage and management costs. Specific examples include mesh deployment models – where each device provides full logging and SIEM functionality – moving real-time processing closer to the event sources. As we described in Understanding and Selecting SIEM/Log Management: the right architecture can deliver the trifecta of fast analysis, comprehensive collection/normalization/correlation of events, and single-point administration – but this requires a significant overhaul of early SIEM architectures. Every vendor meets the basic collection and management requirements, but only a few platforms do well at modern scale and scope. These architectural changes to enhance scalability and extend data types are seriously disruptive for vendors – they typically require a proverbial “brain transplant”: an extensive rebuild of the underlying data model and architecture. But the cost in time, manpower, and disrupted reliability was too high for some early market leaders – as a result some instead opted instead to innovate with sexy new bells and whistles which were easier and faster to develop and show off, but left them behind the rest of the market on real functionality. This is why we all too often see a web console, some additional data sources (such as identity and database activity data) and a plethora of quasi-useful feature enhancements tacked onto a limited scalability centralized server: that option cost less with less vendor risk. It sounds trite, but it is easy to be distracted from the most important SIEM advancements – those that deliver on the core values of analysis and management at scale. Speaking of scalability issues, coinciding with the increased acceptance (and adoption) of managed security services, we are seeing many organizations look at outsourcing their SIEM. Given the increased scaling requirements of today’s security management platforms, making compute and storage more of a service provider’s problem is very attractive to some organizations. Combined with the commoditization of simple network security event analysis, this has made outsourcing SIEM all the more attractive. Moving to a managed SIEM service also allows customers to save face by addressing the shortcomings of their current product without needing to acknowledge a failed investment. In this model, the customer defines the reports and security controls and the service provider deploys and manages SIEM functions. Of course, there are limitations to some managed SIEM offerings, so it all gets back to what problem you are trying to solve with your SIEM and/or Log Management deployment. To make things even more complicated, we also see hybrid architectures in early use, where a service provider does the fairly straightforward network (and server) event log analysis/correlation/reporting, while an in-house security management platform handles higher level analysis (identity, database, application logs, etc.) and deeper forensic analysis. We’ll discuss these architectures in more depth later in this series. But this Security Management 2.0 process must start with the problem(s) you need to solve. Next we’ll talk about how to revisit your security management requirements, ensuring that you take a fresh look at the issues to make the right decision for your organization moving forward. Share:

Here’s to the neighbors. I live in a rural area with a pretty low population density and 1.5 acre lot minimum. My closest neighbor is 60 feet away – most are over 300 feet or more. The area is really quiet. Usually all you can hear are birds. You can see the Milky Way at night. On any given day I may see javelina, coyotes, horny toads, road runners, vultures, hawks, barn owls, cottontails, jackrabbits, ground squirrels, mice, scorpions, one of a half-dozen varieties of snake, and a dozen varieties of birds. If you like nature, it’s a neat place to live. I am very fortunate that the house closest mine is owned by the world’s best neighbor. That’s not some coffee mug slogan – he’s just cool! He always has some incredible project going on – from welding custom turbo brackets to his friend’s drag bike, to machining a custom suspension for his truck from raw blocks of steel. His wife’s cool. And he has the same hobbies I do. He listens to the same radio stations. He drinks the same beer I do. If you need something he’s there to help. When the tree blew over between our properties, he was there to help me prop it back up. When my wife’s car got a flat during my last business trip, he put down his dinner and fixed it as if it was the evening’s entertainment. Every week I drop by with a six pack and we sit in his gi-normous garage/machine shop, and talk about whatever. Living next to the world’s best neighbor was offset by three of the 5 other residents within shouting range being asshats. Yeah, I hate to say it, but they were. Quiet, keep-to-themselves folks, but highly disagreeable and dysfunctional. My mean neighbor – mean until he got cancer, then he got really nice just before he left – was foreclosed on after 2 years struggling with the bank. My really mean neighbor – and I mean the North American pit viper cheat-little-children-out-of-their-lunch-money variety – died. Since snakey left his money to his kids, his lovely new wife could no longer afford the house, and was forced to sell to make ends meet. The neighbor behind me – let’s call him packrat, because he’s never seen a pile of junk he did not want to hoard – was also foreclosed on. After rummaging in his own trash for several months looking for scrap metal to sell, packrat smashed up cars, trailers, camper shells, ATVs, and construction supplies with his backhoe. Selling trash and trashing valuables is a special kind of mental illness. He even did me a favor and knocked over my trees by the property line so I have a full view of the debris field. While I am never happy to see people lose their homes, especially given the banking shenanigans going on all around us, I am in some small way a beneficiary. The bad neighbors are gone and the new neighbors are really nice! The people who replaced snakey are very pleasant. The neighbors across the street are wonderful – I helped them move some of their belongings and ended up talking and drinking beer till the sun went down. And while I am going to have to look at the junk pile behind me for a long time – nobody will be moving into the rat’s nest for some time – no neighbor is better than a deranged one. It dawned on me that, surrounded by nice people, I am now the un-cool neighbor. Oh, well. I plan to throw a party for the block to welcome them – and hopefully they will overlook my snarky personality. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rick and Martin on NetSec Podcast. Adrian’s DR post on Database Auditing. Mike’s DR post on DefCon Kids. Adrian quoted on PCI Council’s guidance on tokenization. Adrian quoted on tokenization. Favorite Securosis Posts Mike Rothman: Hammers and Homomorphic Encryption. Something about saying “homomorphic” makes me laugh. Yes, I’m a two year old… Adrian Lane: Proxies and the Cloud (Public and Private). Yes, you can encrypt SaaS via proxy. It works but it’s clunky. And fragile. Rich: Security Management 2.0: Time to Replace Your SIEM? (new series). This is going to be an awesome series. David Mortman: New White Paper: Tokenization vs. Encryption. Dave Lewis: Nothing Changed: Black Hat’s Impact on ICS Security. Other Securosis Posts Incite 8/17/2011: Back to School. Friday Summary: August 12, 2011. Favorite Outside Posts Mike Rothman: Stop Coddling the Super-Rich. Buffett is the man. No, Rich, Warren. But if we tax the super wealthy more, they may not donate as much to the campaign funds. Dave Lewis: The Three Laws Of Security Professionals. Adrian Lane: 15 Years of Software Security: Looking Back and Looking Forward. I met Adam around this time – and used to pass that guide out to my programming team. David Mortman: Nymwars: Thoughts on Google+. Project Quant Posts DB Quant: Index. NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. NSO Quant: Manage Metrics–Process Change Request and Test/Approve. Research Reports and Presentations Tokenization vs. Encryption: Options for Compliance. Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Top News and Posts Spyeye Source ‘Leaked’. BART Blocks Cell Services. Anonymous says ‘F-U’. Beware of Juice-Jacking. Funny – but how many people forget these are just USB connectors? New Attack on AES. AES is hardly doomed by this, but any progress beating the most popular symmetric cipher is important. Persistent Flash Cookies. Microsoft Security Program & Vulnerability Data Now Available. German hacker collective expels OpenLeaks founder. On immigration, a step in the right direction. IT Admin Hacker Caught By McDonald’s Purchase. Don’t just read the headline on this one – look at

Mike and I are launching our next blog series today, one we know is pretty timely from the conversations with have with organizations almost every day. The reality is that many organizations have spent millions and years trying to get productivity out of their SIEM – with mediocre results. Combined with a number of the large players being acquired by mega IT companies and taking their eyes off the ball a bit, most customers need to start asking themselves some key questions. Is it time? Are you waving the white flag? Has your SIEM failed to perform to expectations despite your significant investment? If you are questioning whether your existing product can get the job done, you are not alone. You likely have some battle scars from the difficulty managing, scaling, and actually doing something useful with SIEM. Given the rapid evolution of SIEM/Log Management offerings – and the evolution of requirements with new application models and this cloud thing – you should be wondering whether there is a better, easier, and less expensive solution to set your needs. As market watchers, we don’t have to be brain surgeons to notice the smaller SIEM and Log Management vendors innovating their various ways to relevance – with new deployment models, data storage practices, analysis techniques, and security features. Some vendors are actively evolving their platforms – adding new capabilities on top of what they have, evolving from SIEM features into broader security management suites. Yet there are others in the space basically “milking the cash cow” by collecting maintenance revenue, while performing the technical equivalent of “putting lipstick on a pig”. (Yes, we just used two farm animal analogies in one sentence.) You may recognize this phenomenon as the unified dashboard approach for hiding obsolescence. Or maybe “Let’s buy another start-up with a shiny object!” … to distract customers from what we haven’t done with our core product strategy. Let’s face it – public company shareholders love milking cash cows, while minimizing additional research and development costs. Security companies (especially those acquired by mega IT) have no problem with this model. Meanwhile customers tend to end up holding the bag, with few options for getting the innovation they need. From our alarmingly consistent conversations with SIEM customers, we know it’s time to focus on this dissatisfaction and open the SIEM replacement process up to public scrutiny. Don’t be scared – in some ways SIEM replacement can be easier than the initial installation (yes, you can breathe a sigh of relief), but only if you leverage your hard-won knowledge and learn from your mistakes. Security Management 2.0: Time to Replace Your SIEM? will take a brutally candid look at triggers for considering a new security management platform, walk through each aspect of the decision, and present a process to migrate – if the benefits of moving outweigh the risks. In this series we will cover: Platform Evolution: We will discuss what we see in terms of new features, platform advancements, and deployment models that improve scalability and performance. We’ll also cover the rise of managed services to outsource, and deploying hybrid configurations. Requirements: We’ll examine the evolution of customer requirements in the areas of security, compliance, and operations management. We will also cover some common customer complaints, but to avoid descending into a customer gripe session, we’ll also go back and look at why some of you bought SIEM to begin with. Platform Evaluation: We’ll help walk through an in-depth examination of our current environment and its effectiveness. This will be a candid examination of what you have today – considering both what works and an objective assessment of what you’re unhappy about. Decision Process: We’ll help re-evaluate your decisions by re-examining original requirements and helping remove bias from the process as you look at shiny new features. Selection Process: This is an in-depth look at how to tell the difference between various vendors’ capabilities, and at which areas are key for your selection. Every vendor will tell you they are “class leading” and “innovative”, but most are not. We’ll help you cut through the BS and determine what’s what. We will also define a set of questions and evaluation criteria to help prioritize what’s important and how to weigh your decision. Negotiation: You will be dealing with an incumbent vendor, and possibly negotiating with a new provider. We’ll help you factor in the reality that your incumbent vendor will try to save the business, and how to leverage that as you move to solidify a new platform. Migration: If you are moving to something else, how do you get there? We’ll provide a set of steps for migration, examining how to manage multiple products during the migration. Don’t assume that SIEM replacement is always the answer – that’s simply not the case. In fact, after this analysis you may feel much better about your original SIEM purchase, with a much better idea (even a plan!) to increase usage and success. But we believe you owe it to yourself and your organization to ask the right questions and to do the work to get those answers. It’s time to slay the sacred cow of your substantial SIEM investment, and figure out objectively what offers you the best fit moving forward. This research series is designed to help. Share:

I am proud to announce the availability of our newest white paper, Tokenization vs. Encryption: Options for Compliance. The paper was written to close some gaps in our existing tokenization research coverage. I believe it is particularly important for two reasons. First, I was unable to find a critical examination of tokenization’s suitability for compliance. There are many possible applications of tokenization, but some of the claimed uses are not practical. Second, I wanted to dispel the myth that tokenization is a replacement technology for encryption, when in fact it’s a complimentary solution that – in some cases – makes regulatory compliance easier. While I was writing the paper, the PCI council did not officially accept tokenization. As of August 12, 2011, the Council does offer guidance (if not full acceptance) on using tokenization as a suitable control for payment data. However, the guidance casts doubt on the suitability of hashing and format preserving encryption as methods to improve security and reduce the scope of an audit – which is consistent with this paper. Please review the PCI official announcement (PDF) for additional information. The paper discusses the use of tokenization for payment data, personal information, and health records. This paper was written to address questions regarding the business applicability of tokenization, and is thus less technical than most of our research papers. I hope you enjoy reading it as much as I enjoyed writing it. A special thanks to Prime Factors for sponsoring this research! Download: Tokenization vs. Encryption: Options for Compliance (PDF) Share:

What would you do if you could go back to school? Seriously. If you could turn back the clock and go back to grade school or even high school? No real responsibility. No one depending on you for food and/or shelter. Gosh, I’d do so many things differently. I’d buy a few shares of Microsoft when they went public (and I’d also send a note to my 1999 self to sell it). Ah, the magic of hindsight. What I wouldn’t do is bitch about it. It’s funny that my kids were actually excited to go back to school. We figured they’d be bitching a lot more, especially given how much fun they have over the summer. Thankfully, they aren’t at the stage where they dread the end of summer vacation and the return to the structure and routine of the school year. The Boss is clearly doing something right because the girls jumped right in. The Boy not so much. Not because he doesn’t like school, but more because time he’s working is time he’s not outside playing ball with his buddies. The biggest thing we try to get across every year is the importance of a strong work ethic. Unless there is an activity right after school, the kids grab a snack and jump right into their homework, which must be done, to The Boss’s satisfaction, before they can do anything else. We’re constantly harping on the fact that hard work can overcome a lot of mistakes and issues. Also that it’s okay to get something wrong and to make mistakes. But it’s not okay not to give it proper effort. The most gratifying thing about it all? Seeing one of the kids “get it.” Last year XX1 spent countless hours preparing for a big test, and she aced it. She saw the direct correlation between hard work and positive results. Rich and I were joking the other day that we both did the bare minimum as long as we could throughout public school. We got by on our charming personalities. Okay, maybe not… All the same, if we applied our current work ethic to our school endeavors? Who knows what we’d accomplish. But we would also miss out on a number of great parties and save some liver damage. Okay, a lot of liver damage. Oh yeah, the balance discussion. That’s one secret we won’t share until the kids graduate from college. So don’t ruin it for us, okay? -Mike Note: Yes, I’m kidding. All work and no play is not the way to go through childhood. Photo credits: “Back to School Bong Sale” originally uploaded by designwallah Incite 4 U Fixing is the hard part: I’m kind of surprised at the tepid response to Microsoft’s $250k prize for advancement of exploit mitigation. Imagine that, folks get paid a bit for finding a bug and being able to exploit it, but now can get paid a lot for actually fixing the issue. I think this is great and we should all applaud Microsoft. First for finally understanding that for the price of one engineer (fully loaded), they could put in place a meaningful economic incentive for a researcher. But also to start driving toward a culture of fixing things instead of just breaking them. Stormy did a great job of making that case as well. – MR And you thought your network was tough…: We often call the DefCon network “The World’s Most Hostile Network” since you can assume at least a few hundred – possibly thousands – of hackers are on it eating their latest software toys. What not everyone knows is that there are actually multiple networks at DefCon, some of which are probably reasonably secure, but that isn’t what I’m going to talk about today. Ryan Barnett over at Tactical Web Application Security wrote a great post on what web apps can learn from casino surveillance. I’m a huge fan of monitoring at all levels, and when it comes to web apps we definitely aren’t doing enough (in most cases). Ryan’s post does a good job of keying in on the main difference between apps and networks (spoiler – is has to do with who is allowed in). As a side note, back in Gartner days Ray Wagner (still there) and myself were proponents of using slot machine security standards for voting machines. But it seems the price of democracy doesn’t won’t cover the same security used for nickel slots. Then again the payout of the voting machines usually isn’t 97% either. – RM DAM market maturing: The Database Activity Monitoring market continues to see activity, with GreenSQL receiving another $2.2 million in venture funding from Atlantic Capital partners. Like children, most startups are not very interesting until they are a couple years old. Companies need to mature both product functionality and vision. GreenSQL is reaching that point: their first product was an open source reverse proxy for SQL statements. Now they offer core SQL statement blocking function like other DAM vendors, but they also offer a performance boost through a database caching service as well. Like the rest of the DAM players, they are morphing into something else – with the addition of masking, usage profiles, and application specific rule sets. Integrating a number of previously separate functions into a more integrated offering. Yet another sign of an increasingly mature market. DAM(n) funny how that happens. With Imperva slated for IPO and lots of interest in the basic monitoring capabilities, expect continued M&A activity. I expect we’ll need to change the way we think about DAM into a larger database security context by this time next year. – AL A different kind of hacking: Most of us were taught that two wrongs don’t make a right. The consistent attacks on law enforcement do nothing but endanger folks who make significant sacrifices. Our own Adrian provided some context about the situation in Arizona for this story about the continued posting of personal information about law

Recently I had a conversation with a security vendor offering a proxy-based solution for a particular problem (yes, I’m being deliberately obscure). Their technology is interesting, but fundamental changes in how we consume IT resources challenge the very idea that a proxy can effectively address this problem. The two most disruptive trends in information technology today are mobility and the cloud. With mobility we gain (and demand) anywhere access as the norm, redistributing access across varied devices. At the same time, cloud computing redefines both the data center and the architectures within data centers. Even a private internal cloud dramatically changes the delivery of IT resources. So both delivery and consumption models change simultaneously and dramatically – both distributing and consolidating resources. What does this have to do with proxies? Generally they have been a great solution to a tough problem. It’s a royal pain to distribute security controls across all endpoints, for both performance and management reasons. For example, there is no DLP or URL filtering solution on the market that can fully enforce the same sorts of rules on an endpoint as on a server. Fortunately for us, our traditional IT architectures naturally created chokepoints. Even mobile users needed them to pipe back into the core for normal business/access reasons – quite aside from security. But we’ve all seen this eroding over time. That erosion now reminds me of those massive calving glaciers that sunk the Titanic – not the slow-movers that created all those lovely fjords. From the networking issues inherent to private cloud, to users accessing SaaS resources directly without going through an enterprise gateway, the proxy model is facing challenges. In some cloud deployments you can’t use them at all. There are a many things I still like proxies for, but here are some rough rules I use in figuring out when they make sense. If you have a bunch of access devices in a bunch of locations, you either need to switch to an agent or reroute everything to the proxy (not always easy to do). Proxies don’t need to be in your core network – they can be in the cloud (like our VPN server, which we use for browsing on public WiFi). This means putting more trust in your cloud provider, depending on what you are doing. Proxies in private cloud and virtualization (e.g., encryption or network traffic analysis) need to account for (potentially) mobile virtual machines within the environment. This requires carefully architecting both physical and virtual networks, and considering how to define provisioning rules for the cloud. With a private cloud, unless you move to agents, you’ll need to build inline virtual proxies, bounce traffic out of the cloud, or find a hypervisor-level proxy (not many today – more coming). Performance varies. But the reality is that the more we adopt cloud, the fewer fixed checkpoints we’ll have, and the more we will have to evolve our definition of ‘proxy’ away from its currently meaning. Share:

Researchers at Microsoft are presenting a prototype of encrypted data which can be used without decrypting. Called homomorphic encryption, the idea is to keep data in a protected state (encrypted) yet still useful. It may sound like Star Trek technobabble, but this is a real working prototype. The set of operations you can perform on encrypted data is limited to a few things like addition and multiplication, but most analytics systems are limited as well. If this works, it would offer a new way to approach data security for publicly available systems. The research team is looking for a way to reduce encryption operations, as they are computationally expensive – their encryption and decryption demand a lot of processing cycles. Performing calculations and updates on large data sets becomes very expensive, as you must decrypt the data set, find the data you are interested in, make your changes, and then re-encrypt altered items. The ultimate performance impact varies with the storage system and method of encryption, but overhead and latency might typically range from 2x-10x compared to unencrypted operations. It would be a major advancement if they could dispense away with the encryption and decryption operations, while still enabling reporting on secured data sets. The promise of homomorphic encryption is predictable alteration without decryption. The possibility of being able to modify data without sacrificing security is compelling. Running basic operations on encrypted data might remove the threat of exposing data in the event of a system breach or user carelessness. And given that every company even thinking about cloud adoption is looking at data encryption and key management deployment options, there is plenty of interest in this type of encryption. But like a lot of theoretical lab work, practicality has an ugly way of pouring water on our security dreams. There are three very real problems for homomorphic encryption and computation systems: Data integrity: Homomorphic encryption does not protect data from alteration. If I can add, multiply, or change a data entry without access to the owner’s key: that becomes an avenue for an attacker to corrupt the database. Alteration of pricing tables, user attributes, stock prices, or other information stored in a database is just as damaging as leaking information. An attacker might not know what the original data values were, but that’s not enough to provide security. Data confidentiality: Homomorphic encryption can leak information. If I can add two values together and come up with a consistent value, it’s possible to reverse engineer the values. The beauty of encryption is that when you make a very minor change to the ciphertext – the data you are encrypting – you get radically different output. With CBC variants of encryption, the same plaintext has different encrypted values. The question with homomorphic encryption is whether it can be used while still maintaining confidentiality – it might well leak data to determined attackers. Performance: Performance is poor and will likely remain no better than classical encryption. As homomorphic performance improves, so do more common forms of encryption. This is important when considering the cloud as a motivator for this technology, as acknowledged by the researchers. Many firms are looking to “The Cloud” not just for elastic pay-as-you-go services, but also as a cost-effective tool for handling very large databases. As databases grow, the performance impact grows in a super-linear way – layering on a security tool with poor performance is a non-starter. Not to be a total buzzkill, but I wanted to point out that there are practical alternatives that work today. For example, data masking obfuscates data but allows computational analytics. Masking can be done in such a way as to retain aggregate values while masking individual data elements. Masking – like encryption – can be poorly implemented, enabling the original data to be reverse engineered. But good masking implementations keep data secure, perform well, and facilitate reporting and analytics. Also consider the value of private clouds on public infrastructure. In one of the many possible deployment models, data is locked into a cloud as a black box, and only approved programatic elements ever touch the data – not users. You import data and run reports, but do not allow direct access the data. As long as you protect the management and programmatic interfaces, the data remains secure. There is no reason to look for isolinear plasma converters or quantum flux capacitors when when a hammer and some duct tape will do. Share: