Research

Adrian here, and happy Friday the 13th! It’s been a week since Independence day, and it feels like it’s been a month. Mike wanted us to comment on our feelings about Independence Day and what freedom means to us. For me that was easy. As as I usually do, I worked on Independence Day. Always. It’s not a day off. To me, taking time off is anathema to independence. I celebrate independence by working, because working is what earns me the right to be free. I’m long past the age of military service to my country, so I serve it by trying to build and contribute. And at this moment I feel very lucky to have the opportunity to work and make a living, and great business partners to work with. There is always a boatload of stuff to do here at Securosis, so I have been quietly ‘celebrating’ my independence by finishing up a bunch of writing. It may sound weird, but that’s just me. It’s also odd, given the amount of writing, that what makes the Friday Summaries fun is that I get to write about whatever captures my interest. This week it’s something that popped up in a Fast Company article, The Many Pivots of Justin.tv, a couple weeks ago. The comment that has been running through the back of my mind is “Free and easy streaming poses a particular threat to sports, whose broadcast rights are so valuable, and so perishable”. Content security was one of my first challenges in security, and has proven unsolvable. I think it’s absolutely fascinating, how technology keeps changing this debate over and over again before our eyes, and to me that quote captures the essence of the entire content security battle. The value of sporting events is ephemeral. Most people won’t watch a game after they know the results, and vanishingly few events have a shelf life longer than a few days. But in order for companies to make money from that content, they need to get it to the consumer – and that is the problem. It’s one of the very first things I learned in security: You can protect digital media, or you can use digital media. It’s one or the other. Try to do both, and you are only as secure as your least trustworthy audience member. So when you send a sporting event to 200,000,000 people, someone will do something you don’t like. You know, record a game, or show sports at a bar. It’s probably difficult to remember, but professional sports are broadcast free of charge. Every week, in every major US city, professional sports games are broadcast over radio and television. These are available free of charge. When cable TV and satellite providers came along, they offered a more reliable picture, and some additional channels, for a fee. They would love for you to forget that there are free broadcasts, and that you are really paying for the distribution network that moves someone else’s content – which may or may not be freely available elsewhere. I bring that up because streaming live sporting events over the Internet is just the technology challenge du jour to closed systems such as satellite and cable TV. Tomorrow it could be iPhones. If 30 years ago rabbit ears had been 1,000 times more sensitive, there would be no cable networks today. If suddenly Sutro Tower in San Francisco was broadcasting at 200,000,000 Watts, you would likely see Bay Area sporting events everywhere in the country – free of charge. And despite over-the-air broadcasts being the de facto model 30 years ago, either technology advancement I described could be legal or illegal today – depending on the wishes of the content owner. Ultimately, if content is being used in a way its creator does not approve of, that’s copyright infringement. If they approve of it, as with Slingbox, it’s okay. If it’s Justin.tv or anyone else, they don’t. The difference is in control. While copyright laws make sense logically, when you physically broadcast media, right or wrong, you lose control. Consumable media cannot effectively be secured. It’s a losing game, but one with huge money at stake. As a content producer myself, I totally back the rights of the people who produce television – especially sporting events. What bothers me is the deep levels of greed from the people who run the distribution channels – who all believe they are losing money to ‘pirates’, and are attempting to criminalize what’s broadcast for free over the air, because they think they are being cheated. They’re all thinking that those 27 million viewers on Justin.tv must be their audience and so they are all mentally dividing up the same pile of virtual money they should be earning. But in reality it’s a new audience, one that only exists with a combination of lower cost and higher convenience. What broadcasters should be doing is looking for a way to monetize the broadcasts before content creators go direct to consumers. You know, like local over-the-air broadcasters did with advertising? They should be thanking Justin.tv for building a market for them to take advantage of, and looking for ways to charge advertisers for the feeds going out. This will be a recurring battle for the next, well, forever. Technology will advance. People will innovate. Markets will evolve to become more efficient. And people who want their sports will look for the best, cheapest, and most satisfying way to get it. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on iOS Security. Adrian’s Let’s Ask “Why?” at Dark Reading. Mike’s Dark Reading Column: Flame’s impact on Patching. Adrian’s 15 Ways to Get More From Log Files on Dark Reading. Favorite Securosis Posts Mike Rothman: Q1 Vendor Newsletter. We launched a quarterly newsletter for our vendor retainer clients. Here’s the inaugural piece, and it kicks butt. The recently completed Q2 version is even better (hint, hint)… Rich: Mike’s latest on endpoint malware

The final installment in our masking series closes with a simplified buyer’s guide for product selection. As with most security product buyer’s guides, we offer a fairly involved process to help customers identify their needs and evaluate solutions against each other. These guides address the difficulty of getting all stakeholders to agree on a set of use cases and priorities, which is harder than it sounds. We also offer guidance on avoiding pitfalls and vendor BS. Of course you still need to ensure that your requirements are identified and prioritized before you start testing, but the process with masking technologies is a bit less complicated than with other technologies. The field of vendors has dwindled rapidly for one simple reasons: Customer requirements are narrowly defined along a few principal use cases (test data management, compliance, and database security), so most masking platforms focus their solutions along these lines. Only a couple full-featured platforms provide the necessary deployment models and sufficient database coverage to compete in all cases. But we often see a full-featured platform pitted against others that focus on a single use case, because not every customer needs or wants every possible capability. So don’t focus solely on ‘leaders’ in whatever analyst reports you may read, but cast your net across a wider group of vendors to start your ‘paper’ evaluations. That should give you a better idea of what’s available before you conduct a proof of concept deployment. Define Requirements Over and over again, we see dissatisfaction with security products stemming from a failure to fully understand internal requirements before product selection. We understand that it is impossible to fully evaluate questions such as ease-of-use across an entire organization before a product is in full deployment. But unfortunately, more often the real issue is lack of understanding of both the internal expectations for the product and where the organization is headed. So defining needs and getting input from all stakeholders are necessary for a successful product evaluation and selection. Create selection team: Even small firms have at least the technically-focused security and IT operations groups cooperate during the selection process; but typically different business units, along with risk, audit, and compliance have input as well. Identify the major stakeholders and designate a spokesperson for each group. Define what needs protecting: You need to identify the systems (file servers, databases, etc.) and data types to be protected. Summarize what the data is and how the systems are used, and map desired data flow if possible. Define how data will be protected: Map your protection and compliance needs to the systems, processes, and data from the previous step. Accept input from each stakeholder on the security and compliance requirements for each data type, and the risk or criticality of that data. Design your ideal deployment: Now that you have an understanding of what needs to be protected and how, document the specifics of integration and deployment. Determine what masks are appropriate for each data type, how data flows through your systems, and where your integration points should be. Define tests: Determine how you will verify that vendors meet your requirements. Decide what samples data sources and data types need to be tested. Confirm that adequate resources are available to thoroughly test the system. Pulling an old laptop from a drawer or an older server from a closet to run tests on is a way to ensure failure. Determine and assign responsibilities for who will test and who will evaluate the results. Tier the tests so the most critical elements are tested first, to weed out unworthy products as quickly as possible. Finally, figure how you will validate the efficacy of the masks, and whether they are genuinely producing suitable results. Formalize requirements: At this point you should have a very clear picture of what you need, so it’s time to document some of your requirements for a formal Request For Information (RFI) and Request For Proposals (RFP) to identify which vendors offer appropriate solutions, and then select the ones that best match your requirements for further evaluation. You should also have a good idea of your budget by this point – it will help guide your selection, and may force a phased deployment. Vendor Selection Deployment Architecture: Architecture is key because it determines compatibility with your environment. It also directly correlates with performance, scalability, management, and ease of deployment. Centralized masking servers, distributed deployments, on-database masking, and agents are all options – but which is best depends entirely on your environment and how you want to deploy. So testing your deployment model across sufficient systems is essential for developing a good idea of how well the masking solution fits your environment. Platform coverage: Verify that the vendors support the relational and quasi-relational databases you need, as well as their ability to work with the applications and file servers you wish to integrate with. This is typically the first area where vendors “wash out” of the evaluation, when they don’t adequately support one of your critical platforms. You should review vendors’ published support matrices, but we suggest you also test your critical platforms to make sure they work to your satisfaction. How data is collected and managed varies from vendor to vendor, and how well each solution works with different database types can be an eye-opening comparison. Use, customization, and management: Test the day-to-day tasks of adding data sources, performing discovery, adding masks, and customizing reports. You will be living with this UI and workflow on a daily basis, so ease of use is a major consideration. If the product is annoying during the evaluation process, it is unlikely to become more pleasant with familiarity. Poor user interfaces make administrators less likely to tune the system, and poor workflows are more likely to cause mistakes. Ease of use is rarely listed as an evaluation criterion, but it should weigh heavily in your choice of platform. Scale and performance: Vendor reported performance and real world performance are quite distinct, so you need

I have been wanting to write a bunch of blog posts for the last few weeks. No, not the heavy research work we have been in up to our eyeballs, but about some of the strange and interesting stuff currently been reported. We used to do a lot more commentary and I miss it. I have a little time this Friday, so I though I would comment on a few of the past week’s articles I think warrant discussion – in many ways as interesting for what was not discussed. Here we go: The first was Google saying that the Internet is a Dangerous Place. OK. Why? Actually, “Why Now?” is a better question – Google has been making a lot of noise lately about security and privacy. I have been getting a dozen or so Google Safe Browsing warnings when visiting web sites, where Safe Browsing has supposedly detected ‘malicious’ or unreliable content. The problem is that every single one of the alerts was bogus! If you look at the details of why Safe Browsing thinks the site is bad, you ll find that all the checks Google lists were passed without detecting any unusual certificates, scripts or content. Take a look at the JavaScript or anything else in the page source, and everything looks sound. I instinctively tend to agree with Google’s assertion, but when I look at the basis for their claim, my own experience with Safe Browsing’s complete unreliability makes me question its validity. I don’t think their assertions are based on solid data. Amrit Williams made a similar tweet a couple weeks ago, saying “Chrome should just be called ‘Warning: We believe state-sponsored attackers may be attempting to compromise your account or computer.’”, and The New York Times ran an article on the same subject. My problem is not that I believe or disbelieve the existence of state sponsored censorship, but I don’t understand the recent hype. It appears to be all FUD, but what is the point? Why is Google being so noisy about security and data integrity? The cynic in me believes that they must be positioning security as a value add, or possibly looking for a legal angle to keep data pure – otherwise why the sudden clamor for attention? Which leads to the second post I found very interesting, on Bruce Schneier’s site, called Apple Patents Data-Poisoning. It appears that the US Patent and Trademark Office believed that poisoning profile data was novel and granted Apple’s patent request. In 2004/2005 I used to provide prospective customers for database activity monitoring a demo script to run against competitive products. The script would simply push SQL queries to both real and non-existent databases over the network. None of the queries would execute successfully because they we not actually part of an active database session. But competitors’ network monitors only looked for SQL queries on any known database port – without regard for whether they were actually going to a database – the monitor would capture all this fake activity. I could poison competitors’ logs with bogus activity, or flood it with false positives. It was a terribly effective way to demonstrate how early database monitoring products that watched network activity sucked. But I would never have tried to patent that idea – it feels like trying to patent network packets: good packets and bad packets are just normal network traffic. Similarly I would not patent my attempts to create “False Adrian” by showing non-random but totally bogus interest in products or services to see what sort of anti-profile I can create, a hobby I have been experimenting with on and off since 2006. This seems like a patent awarded for “urinating on the floor”, or anything else that occurs naturally but fails to identify genuine user intent. From an intellectual property standpoint, I hate to think someone could patent something like this. But from a product standpoint, if Google (and other marketing firms) surreptitiously capturing all your activity for profit pisses you off, would you buy an Apple product that poisons your activity trail? I would. A cloud based iRandomizer for browser traffic over an encrypted tunnel would be ideal! Finally, a post on MSNBC said some hacked firms are “fighting back” by hacking the hackers. Forgive me, but ‘Cloudstrike’ has a very Team America feel to it; well-intentioned but wide of the mark. First, there is a big difference between “active defense” and “strike-back” capabilities. Active defense is not an attack against hackers – it is an active scan of activities on the Internet for clues that someone is, or is about to, launch an attack against your site. Something like the CIA or NSA gathering intelligence to detect someone plotting a terrorist attack. Some large firms use this type of service for advance notice, and they hope to get an early start on their response, whatever it is. But “strike back” capabilities are totally different, and the goal of damaging an alleged attacker would certainly be outside the law. I doubt any of these plans will be effective – the New School blog raises the same question in Active Defense: Show Me the Money. The concept seems well intentioned – some of you are probably unaware that a handful of recent electronic attacks against major companies have been accompanied by physical threats against employees. So I get the desire to induce the same fear in hackers, but it seems unlikely to work, and it’s definitely illegal. Really, you can either locate the attacker(s) or you can’t, but if you can you have a good possibility of scaring them with law enforcement. Otherwise you’re pretty much out of luck. I know some attacked firms have conducted reconnaissance and analysis to help law enforcement locate the attacker, but that seems like the reasonable limit of effectiveness for counter-strike computer security. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on the Security Generation Gap. Mike quoted on the “Renaissance Information

As we approach the end of this series, it has become clear that I should really have started with use cases. Not only because they are the primary driver of interest in masking products, but also because many advanced features and deployment models really only make sense in terms of particular use cases. The critical importance of clustered servers, and the necessity for post-masking validation for some applications, are really only clear in light of particular usage scenarios. I will sort this out in the final paper, putting use cases first, which will help with the more complex later discussions. But here they are. Use Cases Test Data Management: This is, by far, the most important reason customers gave for masking. When polled, most customers say their #1 use for masking technologies is to produce test data. They want to make sure employees don’t do something stupid with corporate data, like making private data sets public, or moving production data to insecure test environments. That is technically true as far as it goes, but fails to capture the essence of what customers look for in masking products. In actuality, masking data for testing and sharing is almost a trivial subset of the full customer requirement; tactical production of test data is just a feature. The real goal is administration of the entire data security lifecycle – including locating, moving, managing, and masking data. The mature version of today’s simpler use case is a set of enterprise data management capabilities which control the flow of data to and from hundreds of different databases. This capability answers many of the most basic security questions we hear customers ask, such as “Where is my sensitive data?” “Who is using it?” and “How can we effectively reduce the risks to that information?” Companies understand that good data makes employees’ jobs easier. And employees are really crafty at procuring data to help with their day jobs, even if it’s against the rules. If salespeople can get the entire customer database to help meet their quotas, or quality assurance personnel think they need production data to test web applications, they usually find ways to get it. The same goes for decentralized organizations where regional offices need to be self-sufficient, or companies need to share data with partners. The mental shift we see in enterprise environments is to stop fight these internal user requirements, but find a way to satisfy this demand safely. In some cases this means automated production of test data on a regular schedule, or self-service interfaces to produce masked content on demand. These platforms are effectively implementing a data security strategy for fast and efficient production of test data. Compliance: Compliance is the second major reason cited by customers for why they buy masking products. Unlike most of today’s emerging security technologies, it’s not just the Payment Card Industry’s Data Security Standard (PCI-DSS) driving sales – many different regulatory controls, across various industry verticals, are driving broad interest in masking. Early customers came specifically from finance, but adoption is well distributed across different segments, including particularly retail, telecomm, health care, energy, education, and government. The diversity of customer requirements makes it difficult to pinpoint any one regulatory concern that stands out from the rest. During discussions we hear about all the usual suspects – including PCI, NERC, GLBA, FERPA, HIPAA, and in some cases multiple requirements at the same time. These days we hear about masking being deployed as a more generic control – customers cite protection of Personally Identifiable Information (PII), health records, and general customer records, among other concerns; but we no longer see every customer focused on one specific regulation or requirement. Now masking is perceived as addressing a general need to avoid unwanted data access, or to reduce exposure as part of an overall compliance posture. For compliance masking is used to protect data with minimal modification to systems or processes which use the (now masked) data. Masking provides consistent coverage across files and databases with very little adjustment. Many customers layered masking and encryption in combination; using encryption to secure data at rest and masking to secure data in use. Customers find masking better at maintaining relationships within databases; they also appreciate that it can be applied dynamically and causes fewer application side effects. In some cases encryption is deployed as part of the infrastructure, while others employ encryption as part of the data masking process – particularly to satisfy regulations that prescribe encryption. But the key difference is that masking offers full control over the data lifecycle from discovery to archival, whereas encryption is used in a more focused manner, often at multiple different points, to address specific risks. Masking platform manage the compliance controls, including which columns of data are to be protected, how they are protected, and where the data resides. Production Database Protection: The first two use cases drive the vast majority of market demand for masking. While replacement of sensitive data – specifically through ETL style deployments – is by far the dominant model, it is not the only way to protect data in a database. At some firms protection of the production database is the primary goal for masking, with test data secondary. Masking can do both, which makes it attractive in these scenarios. Production data generally cannot be fully removed, so this model redirects requests to masked data where possible. This use case centers around protecting information with finer control over user access and dynamic determination whether or not to provide access – something roles and credentials are not designed to support. Dynamic masking effectively redirects suspect queries to a masked view of the real data, along with reverse proxy servers, in a handful of cases. These customers appreciate the dual benefits of dynamically detecting misuse while also monitoring database usage; they find it useful to have a log of which view of information has been presented to which users, and when. It is worth mentioning a few use cases I

In this post we will examine many of the features and functions of masking that go beyond the basics of data collection and transformation. The first, and most important, is the management interface for the masking product. Central management is the core addition that transforms masking from a simple tool into an enterprise data security platform. Central management is not new; but capabilities, and maturity, and integration are evolving rapidly. In the second part of today’s post we will discuss advanced masking functions we are beginning to see, to give you an idea of where these products are heading. Sure, all these products provide management of the basic functions, but the basics don’t fully encompass today’s principal use cases – the advanced feature set and management interfaces differentiate the various products, and are likely to drive your choice of product. Central Management This is the proverbial “single pane of glass” for management of data, policies, data repositories, and task automation. The user interface is how you interact with data systems and control the flow of information. A good UI can simplify your job, but a bad one will make you want to never use the product! Management interfaces have evolved to accommodate both IT management and non-technical stakeholders alike, allowing them to set policy, define workflows, understand risk, and manage where data goes. Some products even provide the capability to manage endpoint agents. Keep in mind that each masking platform has its own internal database to store policies, masks, reports, user credentials, and other pertinent information; and some offer visualization technologies and dashboards to help you see what exactly is going on with your data. The following is a list of management features to consider when evaluating the suitability of a masking platform: Policy Management: A policy is nothing more than a rule on how sensitive data is to be treated. Policies usually consist of a data mask – the thing that transforms data – and a data source the mask is applied to. Every masking platform comes with several predefined masks, as well as an interface to customize masks to your needs. But the policy interfaces go one step further, associating a mask with a data source. Some platforms take this one step further – allowing a policy to be automatically applied to specific data types, such as credit card numbers, regardless of source or destination. Policy management is typically simplified with predefined policy sets, as we will discuss below. Discovery: For most customers discovery has become a must-have feature – not least because it is essential for regulatory compliance. Data discovery is an active scan to first find data repositories, and then scan them for sensitive data. The discovery process works by scanning files and databases, matching content to known patterns (such as 9-digit Social Security numbers) or metadata (data that describes data structure) definitions. As sensitive data is discovered, the discovery tool creates a report containing both the location and a list of the sensitive data types found. Once data is discovered there are many options for what to do next. The report can be sent to interested parties, archived for compliance, or even fed back into the masking product for automatic policy enforcement. The discovery results can be used to build a catalog of metadata, physically map locations within a data center, and even present a risk score based on location and data type. Discovery can be tuned to look in specific locations, refined to look for as few or as many data types as the user is interested in, and automated to find preselected patterns on a regular schedule. Credential Management: Selection, extraction, and discovery of information from different data sources all require credentialed access (typically a user name and password) to the file or database in question. The goal is to automate masking as much as possible, so it would be infeasible to expect users to provide a user name and password to begin every masking task. The masking platform needs to either securely store credentials or use credentials from an access management system like LDAP or Active Directory, and supply seamlessly them as needed. Data Set Management: For managing test data sets, as well as for compliance, you need to track which data you mask and where you send it. This information is used to orchestrate moving data around the organization – managing which systems get which masked data, tracking when the last update was performed, and so on. As an example, think about the propagation of medical records: an insurance company, a doctor’s office, a clinical trial organization, and the federal government, all receive different subsets of the data, with different masks applied depending on which information each needs. This is the core function of data management tools, many of which have added masking capabilities. Similarly, masking vendors have added data management capabilities in response to customer demand for complex data orchestration. The formalization of how data sets are managed is also key for both automation and visualization, two topics we will discuss below. Data Subsetting: For large enterprises, masking is often applied across hundreds or thousands of databases. In these cases it’s incredibly important to be as efficient as possible to avoid overtaxing databases or saturating networks with traffic. People who manage data define the smallest data subset possible that still satisfies application testers’ needs for production quality masked data. This involves cutting down the number of rows exported/viewed, and possibly reducing the number of columns. Defining a common set of columns also helps clone a single masked data set for multiple environments, reducing the computational burden of creating masked clones. Automation: Automation of masking, data collection, and distribution tasks are core functions of every masking platform. The automated application of masking policies, and integration with third party systems that rely on masked data, drastically reduce workload. Some systems offer very rudimentary automation capabilities, such as UNIX cron jobs, while others have very complex features to manage remote jobs and work

If you are interested in discussing use cases and deployment models for Tokenization, you’re in luck! This Thursday (June 14th) at 1pm Eastern, I will be offering a webcast on Tokenization with Intel & McAfee. While many people are looking for scope reduction, reduced audit costs, and simplified security controls for PCI, that does not mean there is only one way to roll out a Tokenization system. There are several options, each with its own advantages, and the best fit depends entirely on your particular goals and how you manage your IT systems. In this webcast I will provide an overview of the three main deployment models and delve into the reasons customers choose each of them. If you are interested you can join us for free by registering: 3 Core Tokenization Models – Choosing the Right PCI DSS Strategy. As always, we will leave time for Q&A at the end. Share:

For whatever reason, I picked up a copy of a magazine my wife received as part of her interior design study work. I was absent-mindedly thumbing through it, waiting for the microwave to heat my coffee, when suddenly one of the the pictures made me stop and pay attention. It was a picture of a woman in a red leather catsuit, posed seductively by a stove. WTF? What is this ad trying to tell me? I must really not be part of their target market – but who is their target market? And another picture, this time a woman on top of a Mercedes, wearing a showgirl costume with lots of makeup. And then a woman with several ‘handymen’ fixing stuff around the house. And so on. Now, I bought a fancy Miele dishwasher, but I didn’t notice my wife responding with a racy outfit. In fact I’m pretty sure “sexy” and “kitchen appliance” are at opposite ends of her universe. I dug a bit deeper, and saw that the articles were on with topics such as: how to keep your junk drawer organized, and the best way to store linen napkins and flatware. I dove into the pile of magazines: Architectural Digest. Cote Sud. English Country Living. They are filled with the same type of content, regardless of country. All I could think was, “Who are they selling this stuff to, exactly?” So I asked my wife. She answered, “It’s all fantasy. They selling women a fantasy about a lifestyle or a way of living they don’t currently have. In some cases it’s what they aspire to, in other cases it’s like a virtual dollhouse. And if people feel they need to go there, they ought to buy a doll house first – have you seen the prices on that stuff?” I looked a little taken aback, so my wife added “Your magazines are the same, that stereo porn you read. It’s all a fantasy.” I say “Nuh-uh. That’s all … wait a minute.” Was she right? I leafed through a couple copies of Stereophile and TAS. Yeah, there are some similarities, posing products in the home. And what the hell is that woman doing on the sofa next to those speakers? I look at some of the home theater trade rags, and now I think she’s got me. Oh, man, I feel silly. Looking for an exception to the rule she’s just thrown down, I think “Ah-ha!” – that can’t be true for business and technology! I go to the land where old technology magazines go to die: the guest bathroom. There must be some old copies of CIO or NetworkWorld, or some such nonsense from way back in 2008 to counter her argument. “My kingdom for a copy of Red Herring!”, and then I found several old magazines. Surely IT can’t be selling fantasy!?! But holy crap, there it was: Cartoons of Microsoft users brandishing swords and holding shields, teaming up to slay mythical IT problems as if they were in some Tolkienesque adventure. The ads show paperless offices, consumer personalization, private clouds, and great ideas that spawn success. User-friendly. Cost-effective. Interactive. Proactive! And then it happened: an ad spoke to me. A Citrix advertisement with a giant hand crushing servers. I must admit I have had that fantasy several times! When pulling an all-nighter in an over-chilled data center because some effing patch wouldn’t apply properly, I would have loved nothing better than to throw that machine out the third-floor data center window. So it was true – it’s all fantasy, and vendors are selling a dream. Even in technology and security, where I thought we were more grounded. With the slow death of print media, websites are not quite as in-your-face about it, but it’s still there. Granted, my experiences never included happy twenty-something models with trendy clothes, all smiling at each other like they just got laid. It was old T-shirts, yesterday’s unshaven faces, and lots of empty diet Pepsi cans in a sea of fast food wrappers. IT technology articles are just as driven by fantasy indulgence as English Country Living, and compared to real everyday lives they are just as absurd. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s 15 Ways to Get More From Log Files, at Dark Reading. Mike quoted on the “Renaissance Information Security Professional”. Favorite Securosis Posts Adrian Lane: Understanding Data Encryption Systems. This is a very simple way to visualize encryption & key management deployments. Other Securosis Posts Incite 6/6/2012: Universally Awesome. Understanding and Selecting Data Masking: Technical Architecture. Friday Summary: June 1, 2012. Favorite Outside Posts Adrian: Jamming Tripoli: Inside Moammar Gadhafi’s Secret Surveillance Network. Long but very interesting article about Internet surveillance. And the sales pitch for surveillance products to the Libyan Government cracked me up – something about “the constant struggle against criminals and terrorism”. Our own Chris Pepper pointed out that it all “sounded unpleasantly familiar.” Ask yourself again why privacy protections are not built into every email tool? Because they would make it very difficult to collect intelligence and monitor rivals – in every country, not just Libya. Rich Mogull: Rob Graham’s Confirmed: LinkedIn 6mil password dump is real. Solid analysis. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Research Reports and Presentations Report: Understanding and Selecting a Database Security Platform. Vulnerability Management Evolution: From Tactical Scanner to Strategic Platform. Watching the Watchers: Guarding the Keys to the Kingdom. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Top News and Posts Crypto breakthrough shows Flame was designed by world-class scientists. Hiding Android Malware. MD5 password scrambler ‘no longer safe’. IE 10’s ‘Do-Not-Track’

Today we will discuss platform architectures and deployment models. Before I jump into the architectural models, it’s worth mentioning that these architectures are designed in response to how enterprises use data. Data is valuable because we use it to support business functions. Data has value in use. The more places we can leverage data to make decisions, the more valuable it is. However, as we have seen over the last decade, data propagation carries many risks. Masking architectures are designed to fit within existing data management frameworks and mitigate risks to information without sacrificing usefulness. In essence we are inserting controls into existing processes, using masking as a guardian, to identify risks and protect data as it migrates through the enterprise applications that automate business processes. As I mentioned in the introduction, we have come a long way from masking as nothing more than a set of scripts run by an admin or database administrator. Back then you connected directly to a database, or ran scripts from the console, and manually moved files around. Today’s platforms proactively discover sensitive data and manage policies centrally, handling security and data distribution across dozens of different types of information management systems, automatically generating masked data as needed for different audiences. Masking products can stand alone, serving disparate data management systems simultaneously, or be embedded as a core function of a dedicated data management service. Base Architecture Single Server/Appliance: A single appliance or software installation that performs static ‘ETL’ data masking services. The server is wholly self-contained – performing all extraction, masking, and loading from a single location. This model is typically used in small and mid-sized enterprises. It can scale geographically, with independent servers in regional offices to handle masking functions, usually in response to specific regional regulatory requirements. Distributed: This option consists of a central management server with remote agents/plug-ins/appliances that perform discovery and masking functions. The central server distributes masking rules, directs endpoint functionality, catalogs locations and nature of sensitive data, and tracks masked data sets. Remote agents periodically receive updates with new masking rules from the central server, and report back sensitive data that has been discovered, along with the results of masking jobs. Scaling is by pushing processing load out to the endpoints. Centralized Architecture: Multiple masking servers, centrally located and managed by a single management server, are used primarily for production and management of masked data for multiple test and analytics systems. Proxy/Bridge Cluster: One or more appliances or agents that dynamically mask streamed content, typically deployed in front of relational databases, to provide proxy-based data masking. This model is used for real-time masking of non-static data, such as database queries or loading into NoSQL databases. Multiple appliances provide scalability and failover capabilities. This may or may not be used in a two-tier architecture. Appliances, software, and virtual appliance options are all available. But unlike most security products, where appliances dominate the market, masking vendors generally deliver their products as software. Windows, Linux, and UNIX support is all common, as is support for many types of files and relational databases. Support for virtual appliance deployment is common among the larger vendors but not universal, so inquire about availability if that is key to your IT service model. A key masking evolution is the ability to apply masking policies across different data management systems (file management, databases, document management, etc.) regardless of platform type (Windows vs. Linux vs. …). Modern masking platforms are essentially data management systems, with policies set at a central location and applied to multiple systems through direct connection or remote agent software. As data is collected and moved from point A to point B, one or more data masks are applied to one or more ‘columns’ of the data. Deployment and Endpoint Options While masking architecture is conceptually simple, there are many different deployment options, each particularly suited to protecting one or more data management systems. And given masking technologies must work on static data copies, live database repositories, and dynamically generated data (streaming data feeds, application generated content, ad hoc data queries, etc.), a wide variety of deployment options are available to accommodate the different data management environments. Most companies deploy centralized masking servers to produce safe test and analytics data, but vendors offer the flexibility to embed masking directly into other applications and environments where large-footprint masking installations or appliances are unsuitable. The following is a sample of the common deployments used for remote data collection and processing. Agents: Agents are software components installed on a server, usually the same server that hosts the data management application. Agents have the option of being as simple or advanced as the masking vendor cares to make them. They can be nothing more than a data collector, sending data back to a remote masking server for processing, or might provide masking as data is collected. In the latter case, the agent masks data as it is received, either completely in memory or from a temporary file. Agents can be managed remotely by a masking server or directly by the data management application, effectively extending data management and collaboration system capabilities (e.g., MS SharePoint, SAP). One of the advantages of using agents at the endpoint rather than in-database stored procedures – which we will describe in a moment – is that all traces of unmasked data can be destroyed. Either by masking in ‘ephemeral’ memory, or by ensuring temporary files are overwritten, sensitive data is not leaked through temporary storage. Agents do consume local processor, memory, and storage – a significant issue for legacy platforms – but only a minor consideration for virtual machines and cloud deployments. Web Server Plug-ins: Technically a form of agent, these plug-ins are installed as web application services, as part of an Apache/web application stack used to support the local application which manages data. Plug-ins are an efficient way to transparently implement masking within existing application environments, acting on the data stream before it reaches the application or extending the application’s functionality

It’s the first of June, and I’m sure most of you are thinking about vacation, if not actually on vacation at this point. I’m here holding down the fort while the rest of Securosis is visiting places cooler and more fun. I’m taking time to reflect on security topics and my research agenda. I have been mulling over the topic of IT buying security products for the sake of security. Sounds irrational, right? We have known for years that people only buy security products to help satisfy compliance requirements, and then only grudgingly, to meet the minimum requirements. But people buying security to help secure things keeps popping up here and there, and I have been waiting for better evidence before blogging about it. Just before the RSA conference I decided to bring it up in an internal meeting, and the conversation went a bit like this: Me: “I think I should mention buying security for the sake of security as a trend.” Partner #1: “Why?” Me: “The number of security driven inquiries has doubled.” Partner #1: “Twice nothing is nothing. Move on.” Me: “Agreed, but twice 3-5% is something to take notice of.” Partner #2: “Where are you getting your data from?” Me: “Customer conversations and anecdotal vendor evidence. At least a dozen, maybe 15 references, since January, mostly in the area of data and database security.” Partner #2: “Meh. Not a great sample pool, or sample size. It’s so small in comparison to compliance it’s an afterthought. It’s really not worth mentioning.” Me: “Yeah, OK, agreed. But the customer questions seem to be driven by risk analysis, and the conversations just seems different. I think we could keep our eyes open on this.” So it’s not really worth talking about, but here I am mentioning it because it keeps popping up. I figured I’d open it up for discussion with our readers, to see what others are seeing. It’s not an actual trend, but it’s interesting – to me, at least. The evidence clearly shows that security is a compliance-driven market, and there is not enough evidence to say we see a real a change. But the conversations are a bit different than they used to be. More often focused on security, more focused on data, with some understanding of risk and a bit of a six-sigma-esque approach to security roadmaps. So maybe it’s not security at all – maybe it’s sophistication of buyers and their internal processes. And why do I care? Because if security or risk is the driver, it changes who buys the products and what features they focus on and ask about – because the use cases differ between security and compliance buyers. I am thinking out loud, but I’d love to hear what’s driving your product selection today. The other issue to talk about is my research agenda. It’s been hectic here since a month before RSA and it’s only just starting to let up. So it’s time to take a breath and look at the topics you want to hear about. Since Mike joined we have really filled out endpoint and network security; and we have continued to do a lot in analytics, data security, and security management. But despite the amount of expertise we have in house, we have done very little with application security, cloud, and access management. WAF management has been among the top 4 items on my research agenda for 2.5 years now, but has yet to percolate to the top. Identity and Access Management for cloud computing is an incredibly confusing topic which I think we could really shed some light on. And there are plenty of interesting technologies for application security we should delve into as well. We will reset the research agenda again soon, so now is a good time to weigh in on the areas you’re most interested in. Oh, and if you visit Arizona in the coming weeks, stay away from flashlights. Apparently they’re dangerous. Yikes! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences The Macalope consults The Mogull Adrian presents on selecting a tokenization strategy. We missed Rich’s TidBITS article on hardening Mac OS X. Favorite Securosis Posts Adrian Lane: Low Hanging Fruit. When my encrypted tunnel failed the other day and email immediately decided to synch, I prayed no one was listening. Made me change all my passwords just in case. Mike Rothman: Pragmatic Key Management: Introduction. Rich had me at Pragmatic. I look forward to this series – crypto is integral to the cloud and we all need to revisit our Bob & Alice flowcharts. Other Securosis Posts White Paper: Understanding and Selecting a Database Security Platform. White Paper: Vulnerability Management Evolution. Security, Metrics, Martial Arts, and Triathlon: a Meandering Friday Summary. Evolving Endpoint Malware Detection: Control Lost. Continuous Learning. Friday Summary: May 18, 2012. Understanding and Selecting Data Masking: How It Works. Understanding and Selecting Data Masking: Defining Data Masking. Favorite Outside Posts Adrian Lane: The Cost of Fixing Vulnerabilities vs. Antivirus Software. Jeremiah asks whether our security investment dollars can be spent better. Most firms I speak with keep metrics to determine whether security programs are helping, improve over time, and provide some hints about the relative cost/benefit tradeoffs of different security investments. The data supports Jeremiah’s assertion. Mike Rothman: E-Soft (e-soft.co.uk) Uses Bogus Copyright Claims to Stifle Research. I guess some companies never learn from others. Security by obscurity is not a winning strategy. How about actually fixing the damn bug? Yeah, that’s too radical. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Malware Analysis Quant: Metrics – Dynamic Analysis. Research Reports and Presentations Report: Understanding and Selecting a Database Security Platform. Vulnerability Management Evolution: From Tactical Scanner to Strategic Platform. Watching the Watchers:

We are pleased to announce the availability of a new research paper, Understanding and Selecting Database Security Platforms. And this paper covers most of the facets for database security today. We started to refresh our original Database Activity Monitoring paper in October 2011, but stopped short when our research showed that platform evolution has stopped converging – and has instead diverged again to embrace independent visions of database security, and splintering customer requirements. We decided our original DAM research was becoming obsolete. Use cases have evolved and vendors have added dozens of new capabilities – they have covered the majority of database security requirements, and expanded out into other areas. These changes are so significant that we needed to seriously revisit our use cases and market drivers, and delve into the different ways preventative and detective data security technologies have been bundled with DAM to create far more comprehensive solutions. We have worked hard to fairly represent the different visions of how database security fits within enterprise IT, and to show the different value propositions offered by these variations. These fundamental changes have altered the technical makeup of products so much that we needed new vocabulary to describe these products. The new paper is called “Understanding and Selecting Database Security Platforms” (DSP) to reflect these major product and market changes. We want to thank our sponsors for the Database Security Platform paper: Application Security Inc, GreenSQL, Imperva, and McAfee. Without sponsors we would not be able to provide our research for free, so we appreciate deeply that several vendors chose to participate in this effort and endorse our research positions. You can download the DSP paper. Share: